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

From: Samita Chakrabarti <[email-masked]>
Date: Thu, 28 Jun 2012 14:01:00 -0400

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

---

From: Abdussalam Baryun <[email-masked]>
Date: Fri, 29 Jun 2012 12:06:17 +0200

+1

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

On 6/28/12, Samita Chakrabarti <[email-masked]> 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)
>