fix some typos

1 files changed, 9 insertions, 9 deletions

diff --git a/NOTES b/NOTES
index e145c51..e125609 100644
--- a/NOTES
+++ b/NOTES
@@ -22,17 +22,17 @@ sender-id/mux:
    |X ? ? ?|       sender ID       |              MUX              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
-   X .. key exchange flag or unencrypted flag?
+   X .. key-exchange flag or unencrypted flag?
    ? .. reserved
 
 
-Key-Exchange (inline):
+inline Key-exchange:
 
-  Idea: Key-Exchange daemons can communicate with other side via link-local IPv6
+  Idea: Key-exchange daemons can communicate with other side via link-local IPv6
   addresses (works with tun and tap, at least on linux...)
   If packets incoming on tun/tap interface are IPv6 and have a link-local source
-  or destination IP, messages are sent to the other side unecrypted and with the
-  X flag set.
+  or destination IP, messages are sent to the other side unencrypted and with
+  the X flag set.
 
   Idea: use crypto role (server/client, left/right, alice/bob) for addressing
 
@@ -43,7 +43,7 @@ Key-Exchange (inline):
 
       (xxxx is a well known number for SATP, i.e is always '5ADB')
 
-  Question: How to handle systems with IPv6 disabled? No inline Key-Exchange
+  Question: How to handle systems with IPv6 disabled? No inline key-exchange
   support in that case? IPv4 Link-local Adresses only have a /16 range and we
   would loose one mux value in that case (or 3 if we also omit network and
   broadcast addresses -> not too bad...)
@@ -69,13 +69,13 @@ Key-Exchange (inline):
   Does this work together with the IPv6 Link-Local address idea from above?
 
 
-  Question: for the first key exchange it makes sense to update the remote
+  Question: for the first key-exchange it makes sense to update the remote
   address in the SA even if the received packets are unauthenticated, but during
   normal operation it is very bad to update the remote addresses, which are the
   result of authenticated packets, in favor of unauthenticated info (aka packets
   with X flag set).
   Idea: have a seperate address list for encrypted/authenticated packets and for
-  unauthenticated packets. If key exchange succeeds the addresses learned by it
+  unauthenticated packets. If key-exchange succeeds the addresses learned by it
   are copied to the address list for encrypted packets.
 
 
@@ -89,7 +89,7 @@ Packet Handling (Marshal/Unmarshal):
   memory. This might even be 64k (the UDP maximum size) because there won't be a
   lot of them allocated at once (maximum one per NumCPU?!).
   Header, Payload and Authtag of EncryptedPacket as well as Type and Payload of
-  PlainPacket are go slices pointing to the underlaying buffer. TheHeader of
+  PlainPacket are go slices pointing to the underlaying buffer. The Header of
   EncryptedPacket und Type of PlainPacket have Getter and Setter which directly
   encode/decode using BigEndian.(Put)?Uint(16|32). All of this shouldn't need any
   mallocs and would therefor be pretty fast.