Hi Zach, Comments inline, bracketed by <RCC></RCC>
Robert Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 (0) 1924 910888 http://www.gridmerge.com <http://www.gridmerge.com/> Zach Shelby wrote:
Robert, Thanks for all the comments, very helpful. I am not sure I could see all of them though with the HTML embedded in your mail. Could you send me that again directly as an attachment? Thanks. See some comments below based on what I could see: On Feb 10, 2010, at 0:53 , Robert Cragie wrote:Hi Zach, I have been through the document and made some corrections (in yellow) and some comments (in cyan) - see attachment. The main things I found were: • Inconsistent terminology. Bar the actual definitions, the terms, 'host', 'node', 'router' and 'Edge Router' should be used throughout, not a 'LoWPAN' variant of them.Yep, will fix.• Some hangovers re. whiteboard and Extended LoWPANThanks for catching those.• DAD not covered - as mentioned belowCorrect, how you do DAD is basically out of scope right now in the draft. The hard part is actually the text defining *when* you SHOULD or MUST perform DAD... Let's get back to this when I see your full comments.• Propagation of RS/RA not coveredHmmm.. It is covered in Section 5.7 with regard to Context. Maybe a new section in Chapter 7 could be added to deal with this more explicitly?
<RCC>With regard to RS, this can only apply on on-link routers as it is indistinguishable from the RFC4861 RS. Therefore there is no guarantee that an on-link router will have valid information disseminated to it. I guess the V flag indicates this to some extent but there does seem to be some implicit assumption that the correct LoWPAN information will percolate to the edges somehow.
With regard to RA, It is implicitly covered to some extent by the content of 6IO and 6SO and how that is disseminated from the Edge Router out into the LoWPAN but the synchronisation mechanism doesn't seem very clear. There is no explicit section on processing RAs that contain 6IO/6SO. Maybe it's not strictly necessary but I think there may be some gaps from a specification point of view.
</RCC>
<RCC>Is this just in extended LoWPANs? In 07 draft, NC would be relayed to the Edge Router and fundamentally made sense in conjunction with the Whiteboard for DAD. Now it only goes to an on-link router, so I guess I don't quite see the point of it anymore unless some specific DAD mechanism is described.</RCC>• Hints at relaying NR/NC but not coveredRight. This would be used by a separate Extended LoWPAN draft. This draft just needs to define the relay code and fields in NR/NC. Maybe a mention of why that code is there could help?
<RCC>There are references throughout which suggest the IID is only formed from the EUI-64. This gives subsequent addresses formed from it different properties wrt. optimism of uniqueness than an IID using 16-bit short addresses, say, it its formation.</RCC>• Assumption that IID will use EUI-64 whereas it could be formed from alternate link-layer address.From Section 5.1:" A LoWPAN node forms a 64-bit Interface Identifier (IID) as specified in Section 6 of [RFC4944]. This may be based on the EUI-64 identifier, an assigned 16-bit short address, or any other appropriate MAC address."Isn't this OK?
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
