[dhcwg] Re: Issue 38: Editorial NITs
Bernard Aboba <aboba@internaut.com> Fri, 14 October 2005 21:33 UTC
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQXBM-0002bB-AS; Fri, 14 Oct 2005 17:33:40 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQXBL-0002ae-3I for dhcwg@megatron.ietf.org; Fri, 14 Oct 2005 17:33:39 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27426 for <dhcwg@ietf.org>; Fri, 14 Oct 2005 17:33:34 -0400 (EDT)
Received: from outbound.mailhop.org ([63.208.196.171] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQXM8-0007P2-8A for dhcwg@ietf.org; Fri, 14 Oct 2005 17:44:48 -0400
Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.51) id 1EQXBJ-0001fK-9M; Fri, 14 Oct 2005 17:33:37 -0400
Received: by internaut.com (Postfix, from userid 1000) id D53635C1A3; Fri, 14 Oct 2005 14:33:38 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by internaut.com (Postfix) with ESMTP id C3F7834FF4; Fri, 14 Oct 2005 14:33:38 -0700 (PDT)
X-Mail-Handler: MailHop Outbound by DynDNS
X-Originating-IP: 67.182.139.247
X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information)
X-MHO-User: aboba
Date: Fri, 14 Oct 2005 14:33:38 -0700
From: Bernard Aboba <aboba@internaut.com>
To: dhcwg@ietf.org
Message-ID: <Pine.LNX.4.61.0510141431450.5653@internaut.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb
Cc: cheshire@apple.com
Subject: [dhcwg] Re: Issue 38: Editorial NITs
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
Sender: dhcwg-bounces@ietf.org
Errors-To: dhcwg-bounces@ietf.org
These changes look ok to me. Unless there is an objection, I would propose we accept them. -------------------------------------------------------------- Issue 38: Editorial NITs Submitter name: Stuart Cheshire Submitter email address: cheshire@apple.com Date first submitted: October 12, 2005 Reference: http://www1.ietf.org/mail-archive/web/dhcwg/current/msg05499.html Document: DNA-16 Comment type: E Priority: S Section: Various Rationale/Explanation of issue: Regarding references, I think RFC792 (ICMP), RFC3118 (Authentication), and RFC3927 (IPv4LL) should be moved to Informative References (none of those are required to implement DNAv4). 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 -------------- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg
- [dhcwg] Re: Issue 38: Editorial NITs Bernard Aboba