Small editorial fixes

Co-authored-by: Kaspar Schleiser <[email protected]>

book/src/tooling/coap.md

@@ -68,7 +68,7 @@ A program that triggers a CoAP request provides[^whatsinarequest] some component
   or if there is an implied security mechanism for the origin.
 
 
-[^whatsinarequest]: These components required for a request are not documented as such in the CoAP RFCs,
+[^whatsinarequest]: The components required for a request are not documented as such in the CoAP RFCs,
     but it is the author's opinion that they are a factual requirement:
     Implementations may implicitly make decisions on those,
     but the decisions are still made.
@@ -77,7 +77,7 @@ A program that triggers a CoAP request provides[^whatsinarequest] some component
 ## Security
 
 The CoAP stack is configured with server and client policies.
-The security mechansims used depend on those selected in the policies.
+The security mechanisms used depend on those selected in the policies.
 
 At this stage, RIOT-rs uses three pieces of security components:
 OSCORE (for symmetric encryption), EDHOC (for key exchange) and ACE (for authentication).
@@ -140,7 +140,7 @@ when disabled, the only sensible policy that is left <!-- "deny everything" is n
 is to allow unauthenticated access everywhere.
 For example, this may make sense on a link layer with tight access control.
 The components also have internal dependencies:
-EDHOC can only practically be used in connection with OSCORE;
+EDHOC can only practically be used in combination with OSCORE;
 ACE depends on either depending on the profiles used.
 
 #### Symmetric encryption: OSCORE