diff --git a/draft-ietf-lsvr-l3dl.xml b/draft-ietf-lsvr-l3dl.xml
index 0aff603..23bd0d1 100644
--- a/draft-ietf-lsvr-l3dl.xml
+++ b/draft-ietf-lsvr-l3dl.xml
@@ -56,17 +56,13 @@
 
   <abstract>
 
-    <t>Used in Massive Data Centers (MDCs), BGP-SPF and similar
-    protocols need IP neighbor discovery, logical link encapsulation
-    data, and Layer 2 liveness.  The Layer 3 Discovery and Liveness
-    protocol provides discovery of the neighbor on a logical link,
-    exchanges supported encapsulations (IPv4, IPv6, ...) with neighbors,
-    discovers encapsulation addresses (Layer 3 / MPLS identifiers), and
-    provides layer 2 liveness checking.  The interface data are pushed
-    directly to a BGP API (for LSVR), obviating the need for centralized
-    topology distribution architectures.  This protocol is intended to
-    be more widely applicable to other upper layer routing protocols
-    which need logical link discovery and characterisation.</t>
+    <t>In Massive Data Centers (MDCs), BGP-SPF and similar routing
+    protocols are used to build topology and reachability databases.
+    These protocols need to discover IP Layer 3 attributes of links,
+    such as logical link IP encapsulation abilities, IP neighbor address
+    discovery, and link liveness.  The Layer 3 Discovery and Liveness
+    protocol specified in this document collects these data, which are
+    then disseminated using BGP-SPF and similar protocols.</t>
 
   </abstract>
 
@@ -93,11 +89,12 @@
     deal with scaling, while BGP-SPF <xref
     target="I-D.ietf-lsvr-bgp-spf"/> provides massive scale-out without
     centralization using a tried and tested scalable distributed control
-    plane, offering a scalable routing solution in Clos and similar
-    environments.  But BGP-SPF and similar higher level device-spanning
-    protocols, e.g. <xref target="I-D.malhotra-bess-evpn-lsoe"/>, need
-    logical link state and addressing data from the network to build the
-    routing topology.  They also need prompt reaction to (logical) link
+    plane, offering a scalable routing solution in Clos <xref
+    target="Clos0"/><xref target="Clos1"/> and similar environments.  But
+    BGP-SPF and similar higher level device-spanning protocols,
+    e.g. <xref target="I-D.malhotra-bess-evpn-lsoe"/>, need logical link
+    state and addressing data from the network to build the routing
+    topology.  They also need prompt reaction to (logical) link
     failure.</t>
 
     <t>Layer 3 Discovery and Liveness (L3DL) provides brutally simple
@@ -140,20 +137,21 @@
       target="I-D.ietf-lsvr-bgp-spf"/>.</t>
       <t hangText="Clos:">A hierarchic subset of a crossbar switch
       topology commonly used in data centers.</t>
-      <t hangText="Datagram:">The L3DL content of a single Ethernet
+      <t hangText="Datagram:">The L3DL content of a single Layer 2
       frame.  A full L3DL PDU may be packaged in multiple Datagrams.</t>
       <t hangText="Encapsulation:">Address Family Indicator and
       Subsequent Address Family Indicator (AFI/SAFI).  I.e. classes of
       layer 2.5 and 3 addresses such as IPv4, IPv6, MPLS, ...</t>
-      <t hangText="Frame:">An Ethernet Layer 2 packet.</t>
+      <t hangText="Frame:">A Layer 2 packet.</t>
       <t hangText="Link or Logical Link:">A logical connection between
       two logical ports on two devices.  E.g. two VLANs between the same
       two ports are two links.</t>
       <t hangText="LLEI:">Logical Link Endpoint Identifier, the unique
       identifier of one end of a logical link, see <xref
       target="llei"/>.</t>
-      <t hangText="MAC Address:">Media Access Control Address,
-      essentially an Ethernet address, six octets.  See <xref
+      <t hangText="MAC Address:">48-bit Layer 2 addresses are assumed
+      since they are used by all widely deployed Layer 2 network
+      technologies of interest, especially Ethernet.  See <xref
       target="IEEE.802_2001"/>.</t>
       <t hangText="MDC:">Massive Data Center, commonly thousands of
       TORs.</t>
@@ -294,9 +292,9 @@
       endpoint(s) reachable from an LLEI.</t>
 
       <t>The HELLO and OPEN, <xref target="open"/>, PDUs, which are used
-      to discover and exchange detailed LLEIs, are mandatory; other PDUs
-      are optional; though at least one encapsulation MUST be agreed at
-      some point.</t>
+      to discover and exchange detailed LLEIs, and the ACK/ERROR PDU,
+      are mandatory; other PDUs are optional; though at least one
+      encapsulation MUST be agreed at some point.</t>
       
       <t>The following is a ladder-style sketch of the L3DL protocol
       exchanges:</t>
@@ -403,8 +401,9 @@
       Datagram, it is set to one.</t>
 
       <t hangText="Datagram Number:">0..127, a monotonically increasing
-      value, modulo 128, see <xref target="RFC1982"/>.  Note that this
-      does not limit an L3DL PDU to 128 frames.</t>
+      value, modulo 128, see <xref target="RFC1982"/> which starts at 0
+      for each PDU.  Note that this does not limit an L3DL PDU to 128
+      frames.</t>
 
       <t hangText="Datagram Length:">Total number of octets in the
       Datagram including all payloads and fields.</t>
@@ -488,7 +487,7 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
     <t>The basic L3DL application layer PDU is a typical TLV (Type
     Length Value) PDU.  It includes a signature to provide optional
     integrity and authentication.  It may be broken into multiple
-    Datagrams, see <xref target="transport"/> </t>
+    Datagrams, see <xref target="transport"/>.</t>
 
 <!--
     protocol "Type:8,Payload Length:16,Payload ...:40,Sig Type:8,Signature Length:16,Signature:40"
@@ -535,15 +534,15 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
       <t hangText="Payload:">The application layer content of the L3DL
       PDU.</t>
 
-      <t hangText="Sec Type:">The type of the Signature.  Type 0, a null
+      <t hangText="Sig Type:">The type of the Signature.  Type 0, a null
       signature, is defined in this document.</t>
 
       <t>Sig Type 0 indicates a null Signature.  For very short PDUs,
       the underlying Datagram cheksums may be sufficient for integrity,
       if not for authentication.</t>
 
-      <t>Sig Type 1, aimed at Trust On First Use, AKA TOFU, is specified
-      in a companion document [ref later].</t>
+      <t>Sig Type 1, aimed at Trust On First Use (TOFU) is specified in
+      a companion document [ref later].</t>
 
       <t>Other Sig Types may be defined in other documents.</t>
 
@@ -580,8 +579,9 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
     LLEIs.</t>
 
     <t>Unfortunately, things can get more complex.  Multiple VLANs can
-    run between those two MACS addresses.  In practice, real devices use
-    the same MAC address on multiple ports and/or sub-interfaces.</t>
+    run between those two MAC addresses.  In practice, many real devices
+    use the same MAC address on multiple ports and/or
+    sub-interfaces.</t>
 
     <t>Therefore, in the general circumstance, a fully described LLEI
     might be as follows:</t>
@@ -857,7 +857,7 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
     <t>Once the devices know each other's LLEIs, know each other's upper
     layer identities, have means to ensure link state, etc., the L3DL
     session is considered established, and the devices SHOULD exchange
-    interface encapsulations, addresses, (and labels).</t>
+    L3 interface encapsulations, L3 addresses, and L2.5 labels.</t>
 
     <t>The Encapsulation types the peers exchange may be IPv4
     Announcement (<xref target="ipv4"/>), IPv6 Announcement (<xref
@@ -881,7 +881,7 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
     <t>Further, to consider a logical link of a type to formally be
     established so that it may be pushed up to upper layer protocols,
     the addressing for the type must be compatible, e.g. on the same
-    IPvX subnet.</t>
+    IP subnet.</t>
 
     <section anchor="encaps" title="The Encapsulation PDU Skeleton">
 
@@ -1152,11 +1152,16 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
   <section anchor="keepalive" title="KEEPALIVE - Layer 2 Liveness">
 
     <t>L3DL devices SHOULD beacon frequent Layer 2 KEEPALIVE PDUs to
-    ensure session continuity.</t>
+    ensure session continuity.  A receiver may choose to ignore
+    KEEPALIVE PDUs.</t>
+
+    <t>An operational deployment MUST BE configured to use KEEPALIVEs or
+    not, either globally, or down to per-link granularity.  Disagreement
+    will result in repeated session break and restablishment.</t>
 
     <t>They SHOULD be beaconed at a configured frequency.  One per
     second is the default.  Layer 3 liveness, such as BFD, may be more
-    aggressive.</t>
+    (or less) aggressive.</t>
 
     <t>If a KEEPALIVE is not received from a peer with which a receiver
     has an open session for a configurable time (default 30 seconds),
@@ -1208,7 +1213,8 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
 
     <t>Vendors or enterprises may define TLVs beyond the scope of L3DL
     standards.  This is done using a Private Enterprise Number <xref
-    target="IANA-PEN"/> followed by free form data.</t>
+    target="IANA-PEN"/> followed by Enterprise Data in a format
+    defined for that Enterprise Number and Ent Type.</t>
 
     <t>Ent Type allows a VENDOR PDU to be sub-typed in the event that
     the vendor/enterprise needs multiple PDU types.</t>
@@ -1242,7 +1248,7 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
 
     <t>Full topology discovery is not appropriate at the L3DL layer, so
     Dijkstra à la IS-IS etc. is assumed to be done by higher level
-    protocols.</t>
+    protocols such as BGP-SPF.</t>
 
     <t>Therefore the LLEIs, link Encapsulations, and state changes are
     pushed North via a small subset of the BGP-LS API.  The upper layer
@@ -1376,15 +1382,17 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
     <t>Many MDC operators have a strange belief that physical walls and
     firewalls provide sufficient security.  This is not credible.  All
     MDC protocols need to be examined for exposure and attack
-    surface.</t>
+    surface.  In the case of L3DL, Authentication and Integrity as
+    provided in [draft-ymbk-l3dl-signing] is stronly recommended.</t>
 
-    <t>It is generally unwise to assume that on the wire Ethernet is
+    <t>It is generally unwise to assume that on the wire Layer 2 is
     secure.  Strange/unauthorized devices may plug into a port.
     Mis-wiring is very common in datacenter installations.  A poisoned
-    laptop might be plugged into a device's port.</t>
+    laptop might be plugged into a device's port, form malicious
+    sessions, etc. to divert, intercept, or drop traffic.</t>
 
-    <t>Malicious nodes/devices could mis-announce addressing, form
-    malicious sessions, etc.</t>
+    <t>Siilarly, malicious nodes/devices could mis-announce
+    addressing.</t>
 
     <t>If OPENs are not being authenticated, an attacker could forge an
     OPEN for an existing session and cause the session to be reset.</t>
@@ -1420,7 +1428,7 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
          </figure>
 
     <t>This document requests the IANA create a registry for L3DL
-    Signature Type, AKA Sig Tyoe, which may range from 0 to 255.  The
+    Signature Type, AKA Sig Type, which may range from 0 to 255.  The
     name of the registry should be L3DL-Signature-Type.  The policy for
     adding to the registry is RFC Required per <xref target="RFC5226"/>,
     either standards track or experimental.  The initial entries should
@@ -1541,8 +1549,24 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
     <?rfc include="reference.RFC.1122"?>
     <?rfc include="reference.I-D.malhotra-bess-evpn-lsoe"?>
     <?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml-doi/reference.DOI.10.1145/2975159.xml?anchor=JUPITER"?>
-  </references>
+    <reference anchor="Clos0" >
+      <front>
+	<title>A study of non-blocking switching networks [PAYWALLED]</title>
+	<author initials="C." surname="Clos" fullname="Charles Clos">
+	  <organization></organization>
+	  </author>
+	<date month="March" year="1953"/>
+        </front>
+      <seriesInfo name="Bell System Technical Journal" value="32 (2), pp 406-424"/>
+      </reference>
+    <reference anchor="Clos1" target="https://en.wikipedia.org/wiki/Clos_network/">
+      <front>
+        <title>Clos Network</title>
+	<author/>
+	<date/>
+        </front>
+      </reference>
+    </references>
     
   </back>
-
 </rfc>