+1 Abdussalam Baryun University of Glamorgan, UK =====================
On 6/28/12, Samita Chakrabarti <[email protected]> wrote: > > Hello All: > > The authors and chairs have been discussing the technical changes in > 6lowpan-nd document before the next revision toward the publication of RFC. > There were major concerns about the many optional features and maintaining > compatibility among the 6lowpan devices and their dynamic configuration > options following this document and we were asked to simplify/clarify. > > > The decision was to replace the optional features as substitutable features > meaning that those features (ABRO, 6CO etc.) are mandatory in 6lowpan-nd in > multi-subnet 6lowpan networks unless one uses a 6lowpan routing protocols or > other provisioning mechanism for address prefix advertisement, context > distribution. Multihop DAD is also non-optional if one uses a multihop > 6lowpan networks without EUI 64bit MAC addresses. > > > So suggested changes: > > > 1) > > 1.5. Substitutable Features > > This document defines the optimization of Neighbor Discovery messages > host-router interfaces and introduces the communication in case of > Route-over topology. > > Unless specified otherwise (in a document that defines a routing > protocol that is used in a 6LoWPAN) this document applies to all > routing protocols. However, because the routing protocol may > provide good alternate mechanisms, this document defines certain > features as "substitutable", meaning they can be substituted by a > routing protocol specification that provides mechanisms achieving > the same overall effect. > > The services described in this document that are not concerned with > distribution of information in the 6LoWPAN or with multihop > mechanisms are expected to be provided as specified in this > document. The multihop prefix distribution by the 6LBR and > multihop Duplicate Address Detection mechanisms, as well as 6LoWPAN > context option are substitutable in the sense defined above. > > A guideline for feature implementation and deployment is provided > at the end of the document. > > > Clarification: > > 2) 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. > > > Thanks, > -Samita > > > > _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
