Hi Robert,
Thanks for the comments, below you'll find merged comments from the authors. On
the nit and grammar related comments I will check those though while doing
editing on nd-10 so don't be bothered that I skip them below. We have started
creating tickets on changes in progress for nd-10.
On May 14, 2010, at 6:26 PM, Robert Cragie wrote:
> page 7:
>
> "EUI-64s are globally unique" - What about the case of spoofed/cloned
> EUI-64s? What would be the effect using this ND? Would it be significant? My
> guess is probably not but it might be worth making this clear
We decided it might take a whole bunch of text to discuss all the issues that
might happen with duplicate EUI-64s. For this spec we simply assume that
EUI-64s are unique thus we don't try to detect duplicates.
> page 8:
>
> "However, the Address Registration mechanism might be useful for other link
> layer technologies" - I would have thought all the mechanisms and
> modifications may apply to other link layer technologies
That should read "this specification" might be useful...
>
> page 9:
>
> The process during which a LoWPAN node sends an Neighbor Solicitation message
> - Is "LoWPAN node" a specific term? If so, needs to be defined. I would also
> suggest it is called 6LoWPAN Node (6LN?) to be consistent
>
> "that allows for sleeping nodes" - 6LoWPAN nodes? Check for this throughout
> the document
I added a ticket to add the term 6LN.
>
> "initial set of default routers" - This might seem pedantic, but "Router"
> (with an uppercase R) is defined in this document and "router" (with a
> lowercase r) is defined in RFC4861 and they are subtly different. Maybe have
> this consistency across the document
We'll try to improve consistency.
>
> page 10:
>
> "which in turn use normal Neighbor Discovery mechanisms to convey this
> information to the hosts" - I think this is questionable; there are some
> differences
>
> "DAD is optional if DHCPv6 is used to assign addresses" - Or an alternative
> address assignment mechanism
We don't know of alternative assignment mechanisms, so let's just talk about
DHCPv6 in this draft.
>
> page 12:
>
> "In this case, the Neighbor Solicitation and Advertisement messages will be
> forwarded between the 6LR and 6LBRs" - This is overloading the original use
> of NS/NA as defined in RFC4861 quite a lot and changing the rules. There
> seemed to be resistance to defining a new message but wouldn't that actually
> be better?
This was the approach in earlier versions of 6lowpan-nd with Neighbor
Registration/Confirmation, but for this draft we chose to use NS/NA across the
board for simplicity, although what you suggest has been discussed. Let's keep
using the same NS/NA message in Section 8.2 as for the base registration for
now unless people run into major implementation problems or we get IESG
comments on this. This is something we should keep in mind though.
> page 16:
>
> C: 1-bit context compression flag - I would add the proposed text at the end
> of the definition to make it clear what this flag is for: "This flag is used
> to manage the context lifecycle based on the recommendations in Section 7.2"
Thanks, ticket added.
>
> page 18:
>
> "and sent to the IPv6 All-Routers multicast address" - There is also a case
> for being able to send unicast as it is possible the host has discovered
> which router it wishes to join the network through by other means, e.g.
> 802.15.4 beacon request. This could potentially limit traffic. Section 5.8.2
> also says it can be sent unicast.
Will look into this.
>
> page 19:
>
> "This includes the Context ID, the prefix" - Possibly some confusion between
> the context prefix and the prefix in the PIO. Maybe clarfication on the
> terminology is needed.
Will try to clarify overall.
>
> page 21:
>
> "or the appropriate IP-over-foo document" - Is this a well-known phrase in
> the IETF community? :-)
Yes ;-)
>
> page 25:
>
> "then care should be taken to ensure that there isn't a flood of ARO-carrying
> messages **sent** to the 6LBR as each router hears an ARO from their
> neighboring routers" - Is this likely to happen with a unicast to 6LBR? (**
> typo 'send' -> 'sent' **)
Some proposals are currently being considered for limiting the amount of NSs.
>
> page 28:
>
> "then the RA MUST be silently ignored" - "Silently ignored" is a tautology.
> Either "silently discarded" or simply "ignored"
Silently ignored is more common in IETF terminology.
>
> page 29:
>
> "The routers periodically send Router Advertisements" - "may periodically
> send"? It is optional, isn't it? Also might be worth mentioning this
> information could be disseminated by other mechanisms.
Periodic sending is a must for Section 8.1 to ensure new information is
disseminated. Section 8.1 already makes it clear that this mechanism is
optional and e.g. a routing protocol might already do this.
>
> page 30:
>
> 8.2.1. Special Message Validation - This is a rather complex rule for NS/NA
> processing as the hop limit processing may well happen before payload
> processing. Could it be made simpler or more logical?
We didn't find anything particularly hard there.
>
> page 31:
>
> "It proceeds to look for the Registration Address in the DAD Table. If an
> entry is found and the recorded EUI-64 is different than the EUI-64 in the
> ARO, then it returns an NA with the ARO Status set to 1 ('Duplicate
> Address'). Otherwise it returns an NA with ARO Status set to zero." - It
> would be really nice if it could also return a 'suggested address'. This
> would complete address assignment without the host having to guess again.
We had the ability to request an address in previous nd versions, but that was
removed due to push-back from people thinking that the point here was address
assignment (which it was not). We don't think it is wise to start adding that
kind of feature here again (although personally I would find it useful). In the
end, this process is only done the first time a node registers a short address
on the LoWPAN so the overhead from trying again in case of a duplicate should
not be significant.
Zach
>
> --
> Robert Cragie (Pacific Gas & Electric)
>
> Gridmerge Ltd.
> 89 Greenfield Crescent,
> Wakefield, WF4 4WA, UK
> +44 1924 910888
> +1 415 513 0064
> http://www.gridmerge.com
>
> _______________________________________________
> 6lowpan mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/6lowpan
--
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
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
