spell check <blush>

draft-ymbk-bgp-discovery-layers.xml

@@ -100,7 +100,7 @@
 	    its loopback addresses for the BGP session endpoint.
 	  </t>
 	  <t>
-	    Support  discoverery of the peers' ASs.
+	    Support  discovery of the peers' ASs.
 	  </t>
 	  <t>
 	    Agree on any BGP session authentication and parameters.
@@ -178,7 +178,7 @@
 	<t>
 	  Each one's attributes, a deployment defined set, e.g.: leaf,
 	  spine, ice cream flavor, ...  These attributes are arbitrary
-	  and operator dependednt.  No assumptions should be made, code
+	  and operator dependent.  No assumptions should be made, code
 	  points assigned,, etc.
 	</t>
 
@@ -345,7 +345,7 @@
       <t>
 	This is similar but not quite the sane as the needs of this IDR
 	Design Team.  E.g., L3DL is designed to meet more complex needs.
-	L3DL's reedecesor, LSOE, <xref target="I-D.ymbk-lsvr-lsoe"/>,
+	L3DL's predecessor, LSOE, <xref target="I-D.ymbk-lsvr-lsoe"/>,
 	was simpler and might be a better candidate for adaptation.  A
 	week's work could customize the design for the IDR Design Team's
 	needs.  But ...
@@ -373,7 +373,7 @@
       The principal problem would appear to be discovery at Layer-3,
       because one neither knows whether to use IPv4 or IPv6.  This is
       exacerbated by the possibility of a potential peer not being on
-      the local subnet, and hence broadcast and simiar techniques may
+      the local subnet, and hence broadcast and similar techniques may
       not be applicable.
     </t>
 
@@ -398,7 +398,7 @@
   <section anchor="layer7" title="Discovery at Layer Seven">
 
     <t>
-      Peer discovery at Layer-7 requires application layer rendezcous
+      Peer discovery at Layer-7 requires application layer rendezvous
       mechanisms analogous to those used by LISP, <xref
       target="RFC6830"/> or the Bitcoin Protocol.
     </t>