Dear Zach, Thanks for the update. Could you have a look at my comments that I gave in response to WGLC for ND-15 (see below)? I thought they were included in ticket #134, but it seems that was not the case.
best regards, Esko 1) Parts on multicast may benefit from some more clarification: section 5.1 "A host would never multicast" -> is this "A host MUST NOT multicast" or SHOULD NOT ? section 5.6 "Multicast addresses are considered to be on-link and are resolved as specified in [RFC4944] or the appropriate IP-over-foo document." However section 5.7 says "As all prefixes but the link-local prefix are always assumed to be off-link", implying the contrary that multicast addresses are always off-link. Also, section 5.6 appears to refer to RFC 4944 Section 9, which is only applicable for mesh-under configurations. What about multicast in route-over configurations? (Should it be made more explicit here?) Finally, the text in 5.6 "All other prefixes are assumed to be off-link [RFC5889]" should perhaps be moved lower, so that it indicates the final case of this section. I.e. to first describe the link-local is on-link case, then the multicast is on-link case, then finally describe the "all other prefixes off-link" case would be clearer I think. 2) Registration lifetime calculation: section 5.8.2. mentions "the maximum Registration lifetime is about 7 days". Taking 65535 units of 60 seconds however, I find 45.5 days? 3) Finally, some typos & minor remarks: section 1.3 last paragraph: "involunterily" -> "involuntarily" section 1.4 "messages in host-router interface and" -> "messages in host-router interfaces and" ? "multhop" -> multihop section 3.1 "mechanism using new Address" ->"mechanism using a new Address" section 3.5 "As Routers send RAs to hosts, and when routers optionally receive RA messages or receive multicast NS messages from other Routers the result is Garbage-collectible NCEs." -> Maybe more clear using: "When Routers send RAs to hosts, and when routers optionally receive RA messages or receive multicast NS messages from other Routers, the result is Garbage-collectible NCEs." section 4.1 "an SLLA option MUST be include" -> abbreviation "SLLA" is not defined on first use. Also not used in RFC 4861 main text, so could be defined here. section 5.5 (last sent.) "use a router it is registered, it" -> "use a router it is registered to, it" overall: The text "section section" appears a few times. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Zach Shelby Sent: Tuesday 24 May 2011 21:59 To: 6lowpan WG Subject: [6lowpan] Fwd: New Version Notification for draft-ietf-6lowpan-nd-16.txt We submitted a new version of ND optimizations for 6LoWPAN, closing the two editorial tickets we had from Prague. In addition we made improvements to the tables at the end of the document (thanks to Carsten) and aligned the title to match HC. These changes do not affect implementations of the specification. http://www.ietf.org/id/draft-ietf-6lowpan-nd-16.txt Zach Begin forwarded message: > From: [email protected] > Date: May 24, 2011 10:53:40 PM GMT+03:00 > To: [email protected] > Cc: [email protected], [email protected], [email protected] > Subject: New Version Notification for draft-ietf-6lowpan-nd-16.txt > > A new version of I-D, draft-ietf-6lowpan-nd-16.txt has been successfully > submitted by Zach Shelby and posted to the IETF repository. > > Filename: draft-ietf-6lowpan-nd > Revision: 16 > Title: Neighbor Discovery Optimization for Low Power and > Lossy Networks (6LoWPAN) > Creation date: 2011-05-24 > WG ID: 6lowpan > Number of pages: 60 > > Abstract: > The IETF 6LoWPAN working group defines IPv6 over Low-power Wireless > Personal Area Networks such as IEEE 802.15.4. This and other similar > link technologies have limited or no usage of multicast signaling due > to energy conservation. In addition, the wireless network may not > strictly follow traditional concept of IP subnets and IP links. IPv6 > Neighbor Discovery was not designed for non-transitive wireless > links. The traditional IPv6 link concept and heavy use of multicast > make the protocol inefficient and sometimes impractical in a low > power and lossy network. This document describes simple > optimizations to IPv6 Neighbor Discovery, addressing mechanisms and > duplicate address detection for 6LoWPAN and similar networks. > > > > > The IETF Secretariat -- Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
