Re: [6lowpan] 6lowpan-nd-18 : Flag for Changes in the document due to IESG comments

[Abdussalam Baryun <[e-mail]>]

+1

Abdussalam Baryun
University of Glamorgan, UK
=====================

On 6/28/12, Samita Chakrabarti <[e-mail]> 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
>
>
>
>