Subject: Re: [6lowpan] Titles of 6LoWPAN RFCs

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 01 Jul 2011 18:20:26 +0200

Le 29/06/2011 13:20, Carsten Bormann a écrit :
> 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.

My reasoned opinion is that there may be something fundamentally wrong 
in inventing the 6lowpan name as if IPv6 for lowpan is some different IPv6.

In various contexts I hear "in this network we don't run IPv6 and we run 
6lowpan".

IPv6-over-802.15.4 is IPv6-over-foo if you wish.  In this sense it needs 
an MTU req, an identifier mapping for address configuration (uni- and 
multi-cast).

IPv6-over-lowpan depends on what lowpan is, and lowpan is not defined 
anywhere.  It is a term invented by 6lowpan to mean something it thinks 
others mean when they don't actually.

Alex

>
> Gruesse, Carsten
>
> _______________________________________________
> 6lowpan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lowpan
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 01 Jul 2011 18:27:19 +0200

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: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Carsten Bormann
>> Sent: Wednesday, June 29, 2011 1:20 PM To: 6lowpan WG Subject:
>> [6lowpan] Titles of 6LoWPAN RFCs
>>
>> You may recall that we went through a little bit of discussion
>> already for 6LoWPAN-ND, which has the same problem.
>>
>> 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
>>
>> 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.
>>
>> 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)
>>
>>  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.
>>
>> 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 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.
>> _______________________________________________ 6lowpan mailing
>> list [email-masked]
> _______________________________________________ 6lowpan mailing list
>  [email-masked] https://www.ietf.org/mailman/listinfo/6lowpan
>

---

From: Samita Chakrabarti <[email-masked]>
Date: Wed, 6 Jul 2011 20:20:29 -0400

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: [email-masked] [mailto:[email-masked]] On Behalf Of Alexandru Petrescu
Sent: Friday, July 01, 2011 9:27 AM
To: [email-masked]
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 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).

> 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

>> (which, as a consequence, also causes the additional characteristic 
>> of lossiness that ROLL has chosen for its "Low-Power/Lossy" moniker).
>>
>> well-known "6LoWPAN" acronym, and we may need to use this acronym to 
>> make sure the document is perceived in the right scope.
>>
>>  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.)
>>
>> -- 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?
>>

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 07 Jul 2011 10:13:18 +0200

Samita,

Thanks for message.

I write some comments below, just two cents worth.

Le 07/07/2011 02:20, Samita Chakrabarti a écrit :
> 6lowpan-nd has 6lowpan specific assumptions - or low power and lossy
>  network assumptions.

ND tailored in the 6lowpan WG has indeed specific modifications.

But, I am not sure what is meant by low power.  I suppose it is not as
if non-6lowpan networks were high-power(?)  It is not as if only
Personal Area Networks (pan in 6lowpan) need low power.  There exist
short radio range low-power networks which are not worn by person.

> It has got some support for 16bit addresses to support 802.15.4
> devices but that part is optional.

This support of 16bit addresses in draft-ietf-6lowpan-nd-17 is
motivated, I believe, by 802.15.4, which is good because it can be
understood.

But, its use in this draft seems strange.

I looked for it.

"16bit" appears precisely once - more should be.
"16 bit" does not appear.
"MAC16" is well defined on page 45 but is never shown in a message
format.  I guess this is because there are too many terms used in this
document about this 16bit address.
"GP16" is well used much throughout the document.  However
its definition is ambiguous because it says:
> GP16: Global Address based on the 802.15.4 Short Address.  This
> address may not be unique.

Is it the GP16 address which may not be unique?  Or is it the 802.15.4
Short Address which may not be unique?

(GP16 must be unique, and IETF has no say about uniqueness of MAC
addresses be them 16bit or 48bit).

Then.

RFC4944 defines an Interface Identifier using the 16 bit PAN ID and the
16 bit short MAC address.  It does _not_ define any Interface Identifier
_not_ using the PAN ID.

In this sense, there may be a conflict between RFC4944 and 6lowpan-nd.

At this point, one may say that the "lowpan" is different than 802.15.4
in that lowpan does not use PAN ID.  Which brings us back to what is a
"lowpan" and, as you say:
> What is the real definition of LLN ?  I suppose, whatever we do,
> RFC4944 and the 6lowpan-nd or lowpan-nd would be tied together.

Tied or exclusive?

Then.

> When a host has configured a non-link-local IPv6 address

Is that a globally-unique address?  Or is it a "GP16" i.e. a global
address which may not be unique? (derived from the 16bit MAC address in
a non-RFC4944 way).

> EUI-64:        64 bits.  This field is used to uniquely identify the
> interface of the registered address by including the EUI-64
> identifier [EUI64] assigned to it unmodified.

I am not sure that reference [EUI64] allows to form EUI64 from a 16bit
short MAC address.  I think that reference recommends to form EUI64 only
from the 48bit MAC addresses.  It says often "MAC-48" and never
"MAC-16".  In this sense, should I believe that 6lowpan-ND Address
Registration Option _never_ registers a IPv6 address derived from a
16bit short MAC address?  I guess I may be wrong, but clarification is
needed.

Moreover, RFC4944 says:
> All 802.15.4 devices have an IEEE EUI-64 address, but 16-bit short
> addresses (Section 3 and Section 12) are also possible.

this "but" further suggesting that 16-bit short addresses are _not_
EUI-64 addresses.

> Address configuration follows [RFC4862].  For an address not derived
> from an EUI-64, the M flag of the RA determines how the address can
> be configured.

This is so complex to understand.

The M flag of RA tells DHCP-vs-RA regardless of the existence of the
term EUI-64.  One could use DHCP to form addresses whose Interface
Identifier is based on EUI-64.

An address _not_ derived from an EUI-64 could be an address using the
16bit short MAC address?  If so, then you mean that only in that
specific case (16bit short MAC addresses) the M flag tells
DHCP-vs-SLAAC?  But the M flag should always tell so, regardless of the
way the Interface Identifier is formed, or even more regardless of how
the EUI-64 is formed (IETF does not define EUI-64).

Are you sure you don't mean "Interface Identifier" when you say
"EUI-64"?  Interface Identifier is extensively used in rfc2464, 4291,
4944, 4861 which are classical for IPv6 implementations.

Or does one mean that when an address is formed from the 16bit short
address then one MUST use DHCP?  I do not agree with this either.  One
could use SLAAC (not DHCP) and short 16-bit addresses very well, as
rfc4944 describes but with PAN-ID.

Does one mean that when an IPv6 address does _not_ use PAN-ID (non
rfc4944) but _does_ use short IPv6 MAC addresses then one MUST use DHCP?
  In that case too, I believe one could still use SLAAC (not necessarily
DHCP) provided one defines a way to form Interface Identifier from the
short 16bit MAC address only (and not use the the PAN ID as RFC4944
does).  I do not know why would one _not_ use PAN ID, and if you do then
please say.

> If the M flag is set in the RA, then DHCPv6 MUST be used to assign
> the address.  If the M flag is not set, then the address can be
> configured by any other means (and duplicate detection is performed
> as part of the registration process).

Is one sure one means so?

First, the M flag mentioned above seems to be the one in RFC4861 (and
not RFC4862 that is cited - rfc4862 says it does not use the M flag page
27).

Second, rfc4862 says "When [M] set, it indicates that addresses are
available via Dynamic Host Configuration Protocol".

Or, what this draft says is "MUST" DHCP, which is much stronger.

Third, rfc4862 says that when M is not set then no information is
available via DHCPv6.  Or, what this draft says is that if M is not set
then the address _can_ be configured by any other means.  This opening
is what this draft says, and not what the rfc4862 says.

I personally disagree with a proposal to use any other dynamic mechanism
than DHCPv6-SLAAC-PPP methods to configure addresses.

> Once an address has been configured it will be registered by
> unicasting a Neighbor Solicitation with the Address Registration
> option to one or more routers.

Does this mean that a node could use SLAAC to configure an address and
then register it to its router with NS?  I do not see why should it use
Address Registration option to achieve that registration.  NA should be
sufficient.  Even a simple RS is often enough.

> A host should choose a sleep time appropriate for its energy
> characteristics, and set a registration lifetime larger than the
> sleep time to ensure the registration is renewed successfully
> (considering e.g. clock drift and additional time for potential
> retransmissions of the re-registration).

But why is not the prefix lifetime used?  I think one could use the
existing prefix lifetime for the purposes of energy saving, instead of
defining new lifetime fields.

Lifetime and in general time is difficult to implement.  We already have
good implementations of ND and all time values are there to be used for
cases such as energy saving and more other cases.

> A host should also consider the stability of the network (how quickly
> the topology changes) when choosing its sleep time (and thus
> registration lifetime).

Yes, the host should consider the stability of the network when choosing
its sleep time.  And the stability of the network could be expressed by
the prefix lifetime, because the prefix is a network prefix; the
lifetime draft proposes is an address lifetime and that is not the
stability of the network but the stability of the address.

> (the maximum Router Lifetime is about 18 hours whereas the maximum
> Registration lifetime is about 45.5 days)

And the maximum reachable/retrans timer, and prefix lifetime are 136years...

In the entire Address Registration discussion - I think existing ND
lifetime fields could be used to achieve the kinds of sleep modes one
needs.  I do not see the necessity of ARO and the registration process.

Alex

> Thanks, -Samita
> [mailto:[email-masked]] On Behalf Of Alexandru Petrescu
> Sent: Friday, July 01, 2011 9:27 AM To: [email-masked] Subject: Re:
>> ND does not have such a strong link to the MAC so there is no
>> point pinpointing 802.15.4 or any specific IEEE.
>
> 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).
>
>> 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
>>
>>
>>> 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.
>>>
>>> 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).
>>>
>>> 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:
>>> 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.
>>>
>>> 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
>>>
>>> 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
>>> -- 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
>>>  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
>>>

---

From: Robert Cragie <[email-masked]>
Date: Thu, 07 Jul 2011 13:23:19 +0100

+1.

I don't think we should get too hung up on WPAN. It's just a name chosen 
for 802.15 WG. It's subjective as to how appropriate it really is. To be 
precise, 802.15.4 is the low power, low data rate WPAN in 802.15 so 
loWPAN is a reasonable, pronounceable abbreviation which implies 
802.15.4 in the context of 802.15 but could mean other similar types of 
network in other contexts.

Robert

On 29/06/2011 12:45 PM, Pascal Thubert (pthubert) wrote:
> 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.
>
> 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
>
>
>> From: [email-masked] [mailto:[email-masked]] On
>> Behalf Of Carsten Bormann
>> Sent: Wednesday, June 29, 2011 1:20 PM
>> To: 6lowpan WG
>> Subject: [6lowpan] Titles of 6LoWPAN RFCs
>>

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 07 Jul 2011 16:29:30 +0200

Le 07/07/2011 14:23, Robert Cragie a écrit :
> +1.
>
> I don't think we should get too hung up on WPAN. It's just a name
> chosen for 802.15 WG. It's subjective as to how appropriate it really
> is. To be precise, 802.15.4 is the low power, low data rate WPAN in
> 802.15 so loWPAN is a reasonable, pronounceable abbreviation which
> implies 802.15.4 in the context of 802.15 but could mean other
> similar types of network in other contexts.

Hmm... except that "W" in WPAN makes little sense on PLC contexts
(RPL has "PLC" in text).

"P" in PAN is risky too because ND may work on short-range yet
non-wearable networks.

"loan" would be more generic - LOw-power Area Network.

Alex

>> point pinpointing 802.15.4 or any specific IEEE. Rather, ND makes
>> sense because of the NBMA nature of the network, and the desire to
>> save multicast operation, which is common to LLNs. So I do not
>> think we need to change ND.
>>

---

From: Jonathan Hui <[email-masked]>
Date: Thu, 7 Jul 2011 10:39:03 -0700

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

---

From: Robert Cragie <[email-masked]>
Date: Thu, 07 Jul 2011 22:53:49 +0100

Alex,

I don't think you're reading what I'm writing. As I said, WPAN was 
chosen by the IEEE for the 802.15 WG. The 802.15 WG is about wireless, 
hence the 'W'. You assume 'personal' means 'wearable', however the IEEE 
actually use 'body' (as in BAN, body area network) for this. I think 
'personal' is simply meant to be the next down in scope from 'local', 
that's all (and 'body' the next down from 'personal'). It really doesn't 
mean much at all. Let's face it, an 802.11 metropolitan mesh network is 
hardly a LAN. 'Wireless' used to be the bakelite box on the mantelpiece.

'6loan' may well have been better. Hindsight is a wonderful thing. Maybe 
'LOL' would have been good for Low-power and Lossy <LOL>. We could go on 
forever.

On a more serious note, I agree with Jonathan about being more precise 
for HC as that is specific. Of his three suggestions, my preference 
would be "Compression Format for IPv6 Datagrams over IEEE 802.15.4-based 
Networks".

Robert

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 08 Jul 2011 09:30:03 +0200

Le 07/07/2011 23:53, Robert Cragie a écrit :
> chosen by the IEEE for the 802.15 WG. The 802.15 WG is about
> wireless, hence the 'W'. You assume 'personal' means 'wearable',
> however the IEEE actually use 'body' (as in BAN, body area network)
> for this. I think 'personal' is simply meant to be the next down in
> scope from 'local', that's all (and 'body' the next down from
> 'personal').

Yes, metropolitan-local-personal-body is logic, as is
train-bus-car-bicycle-monocycle "CAN" which may use 802.15.4.  I think
802.15.4 is a good term, as well as maybe "short distance range GHz
frequency range".

> It really doesn't mean much at all. Let's face it, an 802.11
> metropolitan mesh network is hardly a LAN. 'Wireless' used to be the
> bakelite box on the mantelpiece.
>
> '6loan' may well have been better. Hindsight is a wonderful thing.
> Maybe 'LOL' would have been good for Low-power and Lossy <LOL>. We
> could go on forever.

Lol.

> On a more serious note, I agree with Jonathan about being more
> precise for HC as that is specific. Of his three suggestions, my
> preference would be "Compression Format for IPv6 Datagrams over IEEE
> 802.15.4-based Networks".

I agree with Jonathan suggestions on HC draft titles because they use
the specific term 802.15.4.  I will write separately.

Alex

>>> chosen for 802.15 WG. It's subjective as to how appropriate it
>>> really is. To be precise, 802.15.4 is the low power, low data
>>> rate WPAN in 802.15 so loWPAN is a reasonable, pronounceable
>>> abbreviation which implies 802.15.4 in the context of 802.15 but
>>> could mean other similar types of network in other contexts.
>>
>>>> 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.
>>>>
>>>> point pinpointing 802.15.4 or any specific IEEE. Rather, ND
>>>> makes sense because of the NBMA nature of the network, and the
>>>> desire to save multicast operation, which is common to LLNs.
>>>> 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
>>>>
>>>>
>>>>> [mailto:[email-masked]] 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.
>>>>>
>>>>> 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
>>>>> well-known "6LoWPAN" acronym, and we may need to use this
>>>>> acronym to make sure the document is perceived in the right
>>>>> scope.
>>>>>
>>>>> 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:
>>>>>
>>>>> (April 27, 2010) Neighbor Discovery Optimization for
>>>>> Low-power and Lossy Networks
>>>>>
>>>>> (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 [email-masked]

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 08 Jul 2011 09:50:26 +0200

>      "Compression Format for IPv6 Datagrams in IEEE 802.15.4 Frames"

I agree with the latter rather than former (Frames rather than Networks) 
because 802.15.4-2003 calls them "MAC frame formats" in its section 7.2 
and because rfc2464 calls similar items "Frame Format" in its section 3.

For information, current title is
"Compression Format for IPv6 Datagrams in Low Power and Lossy Networks
                             (6LoWPAN)"
                     draft-ietf-6lowpan-hc-15

Alex

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 8 Jul 2011 10:11:30 +0200

Hello Jonathan:

> 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:

Either works for me. I think the latter is even better.

Pascal

> Behalf Of Jonathan Hui
> Sent: Thursday, July 07, 2011 7:39 PM
> To: Carsten Bormann
> Cc: 6lowpan WG
> 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.
> 
already
> > Superficially, one part of the problem is that the marker that
people
> > One issue with that is that, strictly speaking, 6LoWPAN would
require
> > (which, as a consequence, also causes the additional characteristic
of
> > Still, the misleading four letters WPAN are part of the now
well-known
> > Note that the ROLL WG has a wider scope than the 6LoWPAN WG (it is
at
> > RFC 4944 and IEEE 802.15.4, so using it as-is in generic "LLNs"
would
> > For both HC and ND, I don't think we properly discussed the
attempted
> > Since 6LoWPAN-HC is waiting in the RFC editor queue, blocked for
just

---

From: Geoff Mulligan <[email-masked]>
Date: Mon, 11 Jul 2011 10:07:33 -0600

I think that either would be fine.

	geoff

---

From: Shoichi Sakane <[email-masked]>
Date: Thu, 14 Jul 2011 22:54:00 +0900

> 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 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

---

From: Zach Shelby <[email-masked]>
Date: Mon, 18 Jul 2011 09:39:07 +0300

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

+1

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://www.sensinode.com
http://zachshelby.org  - My blog "On the Internet of Things"
http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297