Re: [dhcwg] Simplification of DNAv4 specification

I propose the following typographical edits relative to
<http://www.drizzle.com/~aboba/DNA/draft-ietf-dhc-dna-ipv4-17.txt>

1 line changed at 9
-- OLD TEXT --
               Detecting Network Attachment (DNA) in IPv4
-- NEW TEXT --
               Detecting Network Attachment in IPv4 (DNAv4)
--------------

1 line changed at 98
-- OLD TEXT --
   [RFC2119].
-- NEW TEXT --
   "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119].

--------------

1 line changed at 159
-- OLD TEXT --
     private addresses as specified in [RFC1918].
-- NEW TEXT --
     private addresses as specified in "Address Allocation for Private
     Internets" [RFC1918].
--------------

1 line changed at 164
-- OLD TEXT --
     not been relinquished, and whose lease has not yet expired.
-- NEW TEXT --
     not been returned to the DHCP server via a DHCP RELEASE message,
     and whose lease has not yet expired.
--------------

3 lines changed at 197
-- OLD TEXT --
   DHCPREQUEST from the INIT-REBOOT state, as described in [RFC2131]
   Section 3.2 and 4.3.2 completes more quickly than the reachability
   test(s).
-- NEW TEXT --
   DHCPREQUEST from the INIT-REBOOT state, as described in Section 3.2
   and 4.3.2 of the DHCP specification [RFC2131], completes more quickly
   than the reachability test(s).
--------------

1 line changed at 219
-- OLD TEXT --
   [b] The host does not know the default gateway(s) on
-- NEW TEXT --
   [b] The host does not know the addresses of any gateway(s) on
--------------

5 lines changed at 238
-- OLD TEXT --
   Note that it's not possible to get more than one reachability test
   response on a given link, because the first one is the only one that
   should be accepted.  Once a valid reachability test response is
   received, validation is complete, and additional responses (if any)
   should be discarded.
-- NEW TEXT --
   Once a valid reachability test response is received, validation is
   complete, and any additional responses should be discarded.
--------------

2 lines changed at 247
-- OLD TEXT --
   The reachability test is performed by sending an ARP Request.  The
   host MUST set the target protocol address (ar$tpa) to the IPv4
-- NEW TEXT --
   The reachability test is performed by sending a unicast ARP Request.
   The host MUST set the target protocol address (ar$tpa) to the IPv4
--------------

1 line changed at 250
-- OLD TEXT --
   address field (ar$spa) to its own IPv4 address.  The ARP Request MUST
-- NEW TEXT --
   address field (ar$spa) to its own candidate IPv4 address.
   The ARP Request MUST
--------------

2 lines changed at 263
-- OLD TEXT --
   acquisition and expiration behavior described in [RFC2131], Section
   4.4.5.
-- NEW TEXT --
   acquisition and expiration behavior described in
   Section 4.4.5 of the DHCP specification [RFC2131].
--------------

6 lines changed at 280
-- OLD TEXT --
   address does not provide the same level of assurance since this may
   require an ARP Request/Reply exchange.  Where the host has moved
   between two private networks, this could result in ARP cache
   pollution.

   Where a host moves from one private network to another, an ICMP Echo
-- NEW TEXT --
   would not be an acceptable way of testing a candidate configuration
   because sending any IP packet generally requires an ARP Request/Reply
   exchange, and as explained above, ARP packets may not be broadcast
   safely until *after* the operability of the candidate configuration
   has been confirmed. Also, where a host moves from one private network
   to another, an ICMP Echo
--------------

1 line changed at 314
-- OLD TEXT --
   broadcast address as specified in [RFC2131] Section 4.4.2.
-- NEW TEXT --
   broadcast address, as specified in Section 4.4.2 of the DHCP
   specification [RFC2131].
--------------

2 lines changed at 318
-- OLD TEXT --
   packet to the broadcast address, as described in [RFC2131] Section
   4.4.1.  If the host supports the Rapid Commit Option [RFC4039], it is
-- NEW TEXT --
   packet to the broadcast address, as described in Section 4.4.1 of the
   DHCP specification [RFC2131].
   If the host supports the Rapid Commit Option [RFC4039], it is
--------------

2 lines changed at 324
-- OLD TEXT --
   DHCPDISCOVER, then it retransmits as specified in [RFC2131] Section
   4.1.
-- NEW TEXT --
   DHCPDISCOVER, then it retransmits as specified in Section
   4.1 of the DHCP specification [RFC2131].
--------------

1 line changed at 327
-- OLD TEXT --
   As discussed in [RFC2131], Section 4.4.4, a host in INIT or REBOOTING
-- NEW TEXT --
   As discussed in Section 4.4.4 of the DHCP specification [RFC2131], a
   host in INIT or REBOOTING
--------------

2 lines changed at 361
-- OLD TEXT --
   [RFC3927], and MUST NOT attempt to use DNAv4 as a shortcut to bypass
   that process.
-- NEW TEXT --
   "Dynamic Configuration of IPv4 Link-Local Addresses" [RFC3927], and
   MUST NOT attempt to use DNAv4 as a shortcut to bypass that process.
--------------

1 line changed at 367
-- OLD TEXT --
   described in [RFC2131] Section 2.3.  Where a host can confirm that it
-- NEW TEXT --
   described in Section 2.3 of the DHCP specification [RFC2131].  Where
   a host can confirm that it
--------------

1 line changed at 370
-- OLD TEXT --
   Local address is deprecated, as noted in [RFC3927] Section 1.9.
-- NEW TEXT --
   Local address is deprecated, as noted in Section 1.9 of the IPv4
   Link-Local specification [RFC3927].
--------------

1 line changed at 375
-- OLD TEXT --
   retransmission algorithm, [RFC2131] Section 3.2 states that the
-- NEW TEXT --
   retransmission algorithm, Section 3.2 of the DHCP specification
   [RFC2131] states that the
--------------

Stuart Cheshire <cheshire@apple.com>
 * Wizard Without Portfolio, Apple Computer, Inc.
 * www.stuartcheshire.org

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg