Hi, Those changes look good or at least good enough to shoot out a new rev and I can clear down all or almost all of my discuss points.
Thanks, S. On 05/29/2012 03:16 AM, 6lowpan issue tracker wrote: > #142: Stephen Farrel's Discuss comments > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > > #1 1.4 - "it is assumed that 6LRs register with all the 6LBRs." is > ambiguous - does it mean each 6LR registers with some 6LBR or s/each/all/ > or s/some/all/ or both? Assuming that all 6LRs are registered with all > 6LBRs would seem to be too difficult and unwise so I think this needs > fixing. > > RESPONSE==> ‘each 6LR to register with all the configured 6LBR in the > 6LowPAN’. This is the intended meaning. We will also flag this with > 6lowpan wg. > > #2 1.4 - Why would probabilistic uniqueness of non-EUI-64-derived > addresses not be sufficient in some networks? If it is, then the "must be > either assigned or checked" seems wrong. > > RESPONSE===> We are consistent with RFC 4862 section 5.4. It is > recommended that non-EUI-64 addresses should be checked for uniqueness if > they are not assigned by a reliable entity. > > #3 3.2 - Does this mean that if I can pretend to be a router I can force > (some) nodes to change their addresses? If so, why is that not mentioned > as an attack in the security considerations? (If IP-address based node > reputation ever evolved for nodes like these then this would be serious > attack - misbehave as addr1, pretend to be a DHCP server and then force > addr1 on some other innocent node.) > > RESPONSE====> Same security consideration as RFC 4862 applies. We will > update the first line of security consideration section to refer to RFC > 4862 to address this comment. Thus it will say: > "The security considerations of IPv6 Neighbor Discovery [RFC4861] and > [RFC4862] apply" > > #4 3.3 - How long is a sleeping node expected to say awake when sending a > registration message? Is that long enough to get an error saying its > chosen address is in use already? If not, then what prevents that node > constantly re-awakening and using the duplicate address (or many identical > such nodes doing that all the time)? > (Saying "A host retransmits...until..." later in that section isn't clear > enough really - there's no 2119 language there at all so I don't know if > that's a MUST or MAY.) > > RESPONSE===> We will make a change in the document to make the optional > behaviors as default (MUST) in order to address Adrian Farrell's comment. > > The draft provides some default recommendations in section 9 and details > behavior are described in section 5.5. Section 3.3 is an overview section > - here we only wanted to give a high-level overview of the protocol. > > > #5 8.1.4 - Is the last sentence here really optional, (everything in > section 8 should be optional, right?) or is that behaviour meant to apply > to all cases? If the latter, it really ought be in 4.2 shouldn't it? Also > there are two 6CO's mentioned there, but its not clear to me at what point > the 2nd is sent (T+5 presumably?) > > RESPONSE===> As per Adrian Farell's comments we are revisitng the optional > behavior sections to make them mandatory by default to reduce confusion > and interoperability issues in the deployment. If 6CO is used, it should > be in the same prefix advertisemnt. ND-19 should address this comment. > > #6 What does "expects" mean in the security considerations? > (Section 11, 2nd para.) That's not 2119 language. Are you saying this > protocol MUST NOT be used if layer 2 security isn't sufficiently strong or > is missing? If not, then what? > > RESPONSE===> > Suggested new text for the 2nd paragraph in security section: > > This specification assumes that the link layer is sufficiently > protected, for instance using MAC sublayer cryptography. Thus, its > threat model is no different from that of IPv6 Neighbor Discovery [RFC > 4861]. The trust model #1, in section 3 of SEND [RFC3756] applies here. > However, any future 6LoWPAN security protocol that applies to Neighbor > Discovery for 6LoWPAN protocol, is out of scope of this document. > > #7 How can "Using link-layer indication for NUD" be a SHOULD deploy but > only a MAY implement? (Table 2, in section 13.) > > RESPONSE====> > Indeed, there is no reference of 'link-layer indication' in the body of > the document, but we listed in the table for a suggestion to the > implementors. We can either take that text out completely from the table > or update the table as : > > | 5.1 | Re-direct Message Acceptance | MUST NOT | MUST NOT | > | | | | | > | |Joining Solicited Node | N/A | N/A | | > Other | Multicast | | | > |Recommend- | Joining all-node Multicast | MUST | MUST | > | ations | Using link-layer indication for | MAY | MAY | > | | NUD | | | > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > > General - The logic as to why mesh-under and route-over are the most > important topologies is not explained here and I don't see why its most > valuable to tackle this problem in a topology-specific manner. It's also > a shame that 1.3 needs to have all nodes implementing this to get any > benefit and that each node must be part of only one network. (The latter > is particularly unfortunate given that sleeping node wake times might > cause such a condition over time.) However, this is maybe not actually a > problem since the protocol doesn't seem to be really specific to those > topologies - is that right? If so, then I'd suggest weakening the language > to say that e.g. the authors or WG are more interested in those > topologies, but that the protocol might work in other contexts too. > > RESPONSE====> 6lowpan working group mainly targets IEEE802.15.4 or similar > lowpower networks and topologies. The mesh and route-over topologies came > from that concept. > We agree, that in the introduction section, we can change the text to say > that the protocol might work in other contexts. In fact BTLE and BACNET > are two other networks which are considering this protocol. > The homogeneous nature of nodes are needed in this solution as this > document does not address operations with existing nodes. A generic > solution in ipv6 network is being addressed and developed in: > http://datatracker.ietf.org/doc/draft-chakrabarti-nordmark-energy-aware- > nd/ > > > Various places: - What's a non-transitive wireless link? > > RESPONSE=====> non-transitive link is defined in RFC 4861 > Non-transitive reachability means packets from A reach B, and > packets from B reach C, but packets from A don't > reach C.) Many radio links exhibit these. > > Abstract - is a bit awkwardly written, some polish could usefully be > applied. > > RESPONSE====> Will be fixed. Others also commented the same. > > 1.1 - I don't get the relevance of the "primarily two types" of lowpan > topology on p5. Only the last sentence of that paragraph seems relevant or > necessary. Similarly with section 1.2 which, other than introducing > terminology seems unnecessary. > RESPONSE===> 6lowpan wg is interested in these two types of topologies as > these two are defined in IEEE 802.15.4. > > > > 1.3 - A number of the goals say "optimize" - is that meant to mean > "improve" or "make the best"? In the latter, case, that would seem to > require more work, e.g. to be able to compare approaches via metrics or > something. Since I don't think that's really needed, I'd say > s/optimize/improve/g would be more correct. (Similarly for > s/minimize/reduce/) > > RESPONSE===> We will try to make this change in the document when > applicable. The goal of optimization is improvement. > _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
