Re: [6lowpan] Titles of 6LoWPAN RFCs

Shoichi Sakane <sakane@tanu.org> Thu, 14 July 2011 13:54 UTC

Return-Path: <sakane@tanu.org>
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 EA98721F88B2 for <6lowpan@ietfa.amsl.com>; Thu, 14 Jul 2011 06:54:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.723
X-Spam-Level:
X-Spam-Status: No, score=-2.723 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, HELO_MISMATCH_ORG=0.611, HOST_EQ_JP=1.265]
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 cFskClqLC1SF for <6lowpan@ietfa.amsl.com>; Thu, 14 Jul 2011 06:54:14 -0700 (PDT)
Received: from mama.tanu.org (z189134.ppp.asahi-net.or.jp [110.4.189.134]) by ietfa.amsl.com (Postfix) with ESMTP id B279221F889F for <6lowpan@ietf.org>; Thu, 14 Jul 2011 06:54:13 -0700 (PDT)
Received: from mactanu.local (unknown [10.1.0.205]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mama.tanu.org (Postfix) with ESMTPSA id B5E7216B1B for <6lowpan@ietf.org>; Thu, 14 Jul 2011 22:54:00 +0900 (JST)
Message-ID: <4E1EF4F8.7070308@tanu.org>
Date: Thu, 14 Jul 2011 22:54:00 +0900
From: Shoichi Sakane <sakane@tanu.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: 6lowpan <6lowpan@ietf.org>
References: <1BB75432-B4F7-4D30-BC0F-31369D11105C@tzi.org> <F40021B7-BA09-4070-AE45-E15EB29F2FC3@cisco.com>
In-Reply-To: <F40021B7-BA09-4070-AE45-E15EB29F2FC3@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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, 14 Jul 2011 13:54:15 -0000

> On one hand, draft-ietf-6lowpan-hc is a bit more specific than low-power
>and lossy networks - it assumes IEEE 802.15.4 addressing at the link layer.

>    "Compression Format for IPv6 Datagrams over IEEE 802.15.4-based Networks"
> or
>    "Compression Format for IPv6 Datagrams in IEEE 802.15.4 Frames"

"IEEE 802.15.4-based Networks" makes sense to me.

If the latter would be "IEEE 802.15.4-based frames", I would agree
with that.  Otherwise, I do prefer the former.  My point is that,
Jonathan mentioned it already, the specification is not only for
IEEE 802.15.4, but it will extend to others.

Shoichi

On 7/8/11 2:39 AM, Jonathan Hui wrote:
>
> For draft-ietf-6lowpan-hc, we should drop the 6LoWPAN acronym and leave it at "IEEE 802.15.4 Networks".  On one hand, draft-ietf-6lowpan-hc is a bit more specific than low-power and lossy networks - it assumes IEEE 802.15.4 addressing at the link layer.  On the other hand, draft-ietf-6lowpan-hc is a bit more generic than Wireless Personal Area Networks.  IEEE 802.15.4 (while a part of the WPAN working group) already has IEEE task groups (some relatively mature) that are extending IEEE 802.15.4 to other types of networks (Smart Utility Networks, Active RFID, Industrial Networks, etc. - many of which are far from being personal and are significantly different from IEEE 802.15.4-2003/2006).  Then there is IEEE P1901.2 (PLC) which is planning to use IEEE 802.15.4 frames.
>
> Note that RFC 4944's title is "Transmission of IPv6 Packets over IEEE 802.15.4 Networks".  draft-ietf-6lowpan-hc updates RFC 4944.
>
> Following that view, we could have:
>      "Compression Format for IPv6 Datagrams over IEEE 802.15.4 Networks".
>
> Alternatively, since draft-ietf-6lowpan-hc is only concerned about the IEEE 802.15.4 frames and not the full IEEE 802.15.4 spec, we could have the following as well:
>      "Compression Format for IPv6 Datagrams over IEEE 802.15.4-based Networks"
> or
>      "Compression Format for IPv6 Datagrams in IEEE 802.15.4 Frames"
>
> --
> Jonathan Hui
>
> On Jun 29, 2011, at 4:20 AM, Carsten Bormann wrote:
>
>> 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