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

Samita Chakrabarti <samita.chakrabarti@ericsson.com> Thu, 28 June 2012 18:01 UTC

Return-Path: <samita.chakrabarti@ericsson.com>
X-Original-To: 6lowpan@ietfa.amsl.com
Delivered-To: 6lowpan@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F9A721F85D5 for <6lowpan@ietfa.amsl.com>; Thu, 28 Jun 2012 11:01:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level:
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id neQwa005FVcw for <6lowpan@ietfa.amsl.com>; Thu, 28 Jun 2012 11:01:09 -0700 (PDT)
Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 50D0121F85C6 for <6lowpan@ietf.org>; Thu, 28 Jun 2012 11:01:09 -0700 (PDT)
Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q5SI1488020626; Thu, 28 Jun 2012 13:01:06 -0500
Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.50]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Thu, 28 Jun 2012 14:01:01 -0400
From: Samita Chakrabarti <samita.chakrabarti@ericsson.com>
To: "6lowpan@ietf.org" <6lowpan@ietf.org>
Date: Thu, 28 Jun 2012 14:01:00 -0400
Thread-Topic: 6lowpan-nd-18 : Flag for Changes in the document due to IESG comments
Thread-Index: Ac1VV/nYGPOfP4AtQHGVzgTdemWrjg==
Message-ID: <16D60F43CA0B724F8052D7E9323565D72AB81F0ADA@EUSAACMS0715.eamcs.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_16D60F43CA0B724F8052D7E9323565D72AB81F0ADAEUSAACMS0715e_"
MIME-Version: 1.0
Cc: Geoff Mulligan <geoff@proto6.com>, 'Erik Nordmark' <nordmark@cisco.com>, Carsten Bormann <cabo@tzi.org>, Ralph Droms <rdroms@cisco.com>
Subject: [6lowpan] 6lowpan-nd-18 : Flag for Changes in the document due to IESG comments
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6lowpan>, <mailto:6lowpan-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/6lowpan>
List-Post: <mailto:6lowpan@ietf.org>
List-Help: <mailto:6lowpan-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lowpan>, <mailto:6lowpan-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Jun 2012 18:01:11 -0000

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