Re: [6lowpan] Titles of 6LoWPAN RFCs

Samita Chakrabarti <samita.chakrabarti@ericsson.com> Thu, 07 July 2011 00:20 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 B160221F8507 for <6lowpan@ietfa.amsl.com>; Wed, 6 Jul 2011 17:20:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.599
X-Spam-Level:
X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DThaRygUYDN6 for <6lowpan@ietfa.amsl.com>; Wed, 6 Jul 2011 17:20:39 -0700 (PDT)
Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id C8BD421F8591 for <6lowpan@ietf.org>; Wed, 6 Jul 2011 17:20:39 -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 p670Kasx026256; Wed, 6 Jul 2011 19:20:37 -0500
Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.121]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Wed, 6 Jul 2011 20:20:30 -0400
From: Samita Chakrabarti <samita.chakrabarti@ericsson.com>
To: Alexandru Petrescu <alexandru.petrescu@gmail.com>, "6lowpan@ietf.org" <6lowpan@ietf.org>
Date: Wed, 6 Jul 2011 20:20:29 -0400
Thread-Topic: [6lowpan] Titles of 6LoWPAN RFCs
Thread-Index: Acw4C+bHkK6vxzwRRI62/M3YACuliAELu7iA
Message-ID: <16D60F43CA0B724F8052D7E9323565D71E6717EA48@EUSAACMS0715.eamcs.ericsson.se>
References: <1BB75432-B4F7-4D30-BC0F-31369D11105C@tzi.org> <6A2A459175DABE4BB11DE2026AA50A5D04FAE351@XMB-AMS-107.cisco.com> <4E0DF567.1020207@gmail.com>
In-Reply-To: <4E0DF567.1020207@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [6lowpan] Titles of 6LoWPAN RFCs
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, 07 Jul 2011 00:20:40 -0000

6lowpan-nd has 6lowpan specific assumptions - or low power and lossy network assumptions. It has got some support for 16bit addresses to support 802.15.4 devices but that part is optional. 

What is the real definition of LLN ?  I suppose, whatever we do, RFC4944 and the 6lowpan-nd or lowpan-nd would be tied together.

Thanks,
-Samita 

-----Original Message-----
From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Alexandru Petrescu
Sent: Friday, July 01, 2011 9:27 AM
To: 6lowpan@ietf.org
Subject: Re: [6lowpan] Titles of 6LoWPAN RFCs

Le 29/06/2011 13:45, Pascal Thubert (pthubert) a écrit :
> Hi Carsten:
>
> Maybe the answer depends on the draft. HC depends on the 802.15.4 for 
> some of the compression procedure and it makes sense that this appears 
> in the title.
>
> ND does not have such a strong link to the MAC so there is no point 
> pinpointing 802.15.4 or any specific IEEE.

This is so wrong (sorry).

ND is fundamentally related to IEEE stuff, at least in the way it forms addresses.

An ND for 802.15.4 could, for example, tell that Routers must MLD REPORT and then 802.15.4-join (a kind of MAC message).

> Rather, ND makes sense because of the NBMA nature of the network, and 
> the desire to save multicast operation, which is common to LLNs.

Yes, and the conceptual NBMA nature is illustrated in practical terms of ND when an RS is sent to ff02::2 (an IP address) which is 33:33::2 (an IEEE MAC address).

Multicast operation is a common link-layer operation in all Ethernet and its family, not necessarily LLN.

Alex

> So I do not think we need to change ND.
>
> Finally, 6LoWPAN as a name as become a lot more than what the acronym 
> could initially stand for. I do not think the drafts should use 
> 6LoWPAN for what it expands to, but rather as the name of the WG that 
> defined all those drafts.
>
> Cheers,
>
> Pascal
>
>
>> -----Original Message----- From: 6lowpan-bounces@ietf.org 
>> [mailto:6lowpan-bounces@ietf.org] On Behalf Of Carsten Bormann
>> Sent: Wednesday, June 29, 2011 1:20 PM To: 6lowpan WG Subject:
>> [6lowpan] Titles of 6LoWPAN RFCs
>>
>> While completing the RFC editor work for 6LoWPAN-HC, the issue of 
>> supplying correct and useful titles for our RFCs came up again.
>> You may recall that we went through a little bit of discussion 
>> already for 6LoWPAN-ND, which has the same problem.
>>
>> The exposition of the problem takes a couple of paragraphs, so bear 
>> with me, please.
>>
>> Superficially, one part of the problem is that the marker that people 
>> are using to find our work, 6LoWPAN, was built out of the WPAN 
>> abbreviation invented by IEEE.
>>
>> One issue with that is that, strictly speaking, 6LoWPAN would require 
>> a double expansion in an RFC title as in
>>
>> 6LoWPAN (IPv6 over Low Power WPAN (Wireless Personal Area
>> Networks))
>>
>> WPAN also is a bad short-term politically motivated term -- it was  
>> needed in IEEE to get the 802.15.4 radio accepted under 802.15.
>> WPAN ("Wireless Personal Area Networks") is highly misleading, as 
>> there is nothing at all "Personal Area" about 802.15.4 WPANs. The 
>> deciding characteristic is the low-power, limited-range design 
>> (which, as a consequence, also causes the additional characteristic 
>> of lossiness that ROLL has chosen for its "Low-Power/Lossy" moniker).
>>
>> Still, the misleading four letters WPAN are part of the now 
>> well-known "6LoWPAN" acronym, and we may need to use this acronym to 
>> make sure the document is perceived in the right scope.
>>
>> In the recent history of 6LoWPAN-HC being fixed up to address WGLC  
>> comments, there was a silent title change.
>>
>> HC-13 used the title: (September 27, 2010) Compression Format for
>> IPv6 Datagrams in 6LoWPAN Networks HC-14 changed this to:
>> (February 14, 2011) Compression Format for IPv6 Datagrams in Low 
>> Power and Lossy Networks (6LoWPAN)
>>
>> This borrows ROLL's term "Low-Power and Lossy Networks", which may  
>> seem natural to the authors, who have done a lot of work in ROLL.
>>  Note that the ROLL WG has a wider scope than the 6LoWPAN WG (it is 
>> at layer three, connecting different link layer technologies), so it 
>> may be useful to retain a distinction between 6LoWPANs and LLNs.
>>
>> Specifically, 6LoWPAN-HC as defined has a lot of dependencies on RFC 
>> 4944 and IEEE 802.15.4, so using it as-is in generic "LLNs"
>> would be inappropriate.  (It sure can be adapted for many non-6LoWPAN 
>> LLNs, but that would be a separate draft.)
>>
>> 6LoWPAN-ND has a similar problem.  Indeed, some of the concepts of  
>> 6LoWPAN-ND may be applicable to a lot of networks that benefit from 
>> relying less on multicast.  In an attempt to widen the scope, there 
>> was a title change when we rebooted the ND work to simplify
>> it:
>>
>> ND-08: (February 1, 2010) 6LoWPAN Neighbor Discovery ND-09: (April 
>> 27, 2010) Neighbor Discovery Optimization for Low-power and Lossy 
>> Networks
>>
>> However, the document as it passed WGLC still is focused on 6LoWPANs 
>> (e.g., it contains specific support for 6COs).
>>
>> For both HC and ND, I don't think we properly discussed the attempted 
>> title changes in the WG.
>>
>> So what are the specific issues to be decided? I see at least:
>>
>> -- Should we drop the 6LoWPAN marker from our documents? (Note that 
>> RFC 4944 doesn't have it, but in the 4 years since, the term has 
>> gained some recognition.) Should there be another common marker? -- 
>> E.g., should we change over the whole documents (HC, ND) to LLN? -- 
>> Should we just refer to IEEE 802.15.4 in the title (no 6LoWPAN)? HC = 
>> Compression Format for IPv6 Datagrams over IEEE
>> 802.15.4
> Networks
>> ND = Neighbor Discovery Optimization for IEEE 802.15.4 Networks -- Or 
>> should we stick with 6LoWPAN in both title and body? -- If the 
>> latter, what is an appropriate expansion of 6LoWPAN? Can we get rid 
>> of the "Personal" in the expansion? -- IPv6 over Low power Wireless 
>> Personal Area Networks [RFC4944] -- IPv6-based Low power Wireless 
>> Personal Area Networks [RFC4944] -- IPv6 over Low-Power Wireless Area 
>> Networks -- IPv6-based Low-power WPANs -- Other ideas? -- Whatever we 
>> decide about the above: What is the relationship between the 
>> well-known term 6LoWPAN and ROLL LLNs?
>>
>> Since 6LoWPAN-HC is waiting in the RFC editor queue, blocked for just 
>> this title issue, I'd like to resolve these questions quickly.
>> Please provide your reasoned opinion to this mailing list by July 1.
>>
>> Gruesse, Carsten
>>
>> _______________________________________________ 6lowpan mailing list 
>> 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan
> _______________________________________________ 6lowpan mailing list  
> 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan
>

_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www.ietf.org/mailman/listinfo/6lowpan