No, I think it is better to have IEEE802.15.4 out of the title for now= , until we get a generic draft for other WPAN, for 6LoWPAN of most WPAN,

then we may amend the title of 6LoWPAN-HC=A0 and 6LoWPAN-ND

=A0

> -- If the latter, what is an appropriate expansion of 6LoWPAN?>=A0=A0=A0 Can we get rid of the "Personal" in the expansion?=

No, the work already done was for WPAN, and taking it out may need the= =A0considerations of WLAN limitations,

and it is better to separate WPAN and WLAN as gained recognition of: = =A0IEEE802.11 and IEEE802.15

>=A0=A0=A0 -- IPv6 over Low power Wireless Personal Area Networks [= RFC4944]=A0=A0=A0=A0=A0 (b)
>=A0=A0=A0 -- IPv6-based Low power Wirele= ss Personal Area Networks [RFC4944]=A0=A0 (a)

Yes, this maybe recommended (a), or the above (b), but=A0looking forwa= rd for another draft that gains the generic scop

of IPv6 over LLN, that refers to RFC4944 and other draft that should b= e considered,

>=A0=A0=A0 -- Other ideas?
there always be other ideas, but = adding drafts with amendments=A0maybe better than changing=A0drafts=A0with= =A0amendments

> -- Whatever we decide about the above:
>=A0=A0=A0 What is t= he relationship between the well-known term 6LoWPAN and
>=A0=A0=A0 RO= LL LLNs?

I am not sure, I think=A0they have different architecture. However, th= is is overall an important issue to be clarified

=A0

Regards

=A0

Abdussalam Baryun

Research, ICRC

--0016364ef4a26aa25204a72bf15c-- From samita.chakrabarti@ericsson.com Wed Jul 6 17:20:40 2011 Return-Path: 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 To: Alexandru Petrescu , "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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 00:20:40 -0000 6lowpan-nd has 6lowpan specific assumptions - or low power and lossy networ= k assumptions. It has got some support for 16bit addresses to support 802.1= 5.4 devices but that part is optional.=20 What is the real definition of LLN ? I suppose, whatever we do, RFC4944 an= d the 6lowpan-nd or lowpan-nd would be tied together. Thanks, -Samita=20 -----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 =E9crit : > Hi Carsten: > > Maybe the answer depends on the draft. HC depends on the 802.15.4 for=20 > some of the compression procedure and it makes sense that this appears=20 > in the title. > > ND does not have such a strong link to the MAC so there is no point=20 > 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 add= resses. An ND for 802.15.4 could, for example, tell that Routers must MLD REPORT an= d then 802.15.4-join (a kind of MAC message). > Rather, ND makes sense because of the NBMA nature of the network, and=20 > 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 M= AC address). Multicast operation is a common link-layer operation in all Ethernet and it= s 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=20 > could initially stand for. I do not think the drafts should use=20 > 6LoWPAN for what it expands to, but rather as the name of the WG that=20 > defined all those drafts. > > Cheers, > > Pascal > > >> -----Original Message----- From: 6lowpan-bounces@ietf.org=20 >> [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=20 >> supplying correct and useful titles for our RFCs came up again. >> You may recall that we went through a little bit of discussion=20 >> already for 6LoWPAN-ND, which has the same problem. >> >> The exposition of the problem takes a couple of paragraphs, so bear=20 >> with me, please. >> >> Superficially, one part of the problem is that the marker that people=20 >> are using to find our work, 6LoWPAN, was built out of the WPAN=20 >> abbreviation invented by IEEE. >> >> One issue with that is that, strictly speaking, 6LoWPAN would require=20 >> 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 =20 >> needed in IEEE to get the 802.15.4 radio accepted under 802.15. >> WPAN ("Wireless Personal Area Networks") is highly misleading, as=20 >> there is nothing at all "Personal Area" about 802.15.4 WPANs. The=20 >> deciding characteristic is the low-power, limited-range design=20 >> (which, as a consequence, also causes the additional characteristic=20 >> of lossiness that ROLL has chosen for its "Low-Power/Lossy" moniker). >> >> Still, the misleading four letters WPAN are part of the now=20 >> well-known "6LoWPAN" acronym, and we may need to use this acronym to=20 >> make sure the document is perceived in the right scope. >> >> In the recent history of 6LoWPAN-HC being fixed up to address WGLC =20 >> 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=20 >> Power and Lossy Networks (6LoWPAN) >> >> This borrows ROLL's term "Low-Power and Lossy Networks", which may =20 >> 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=20 >> at layer three, connecting different link layer technologies), so it=20 >> may be useful to retain a distinction between 6LoWPANs and LLNs. >> >> Specifically, 6LoWPAN-HC as defined has a lot of dependencies on RFC=20 >> 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=20 >> LLNs, but that would be a separate draft.) >> >> 6LoWPAN-ND has a similar problem. Indeed, some of the concepts of =20 >> 6LoWPAN-ND may be applicable to a lot of networks that benefit from=20 >> relying less on multicast. In an attempt to widen the scope, there=20 >> was a title change when we rebooted the ND work to simplify >> it: >> >> ND-08: (February 1, 2010) 6LoWPAN Neighbor Discovery ND-09: (April=20 >> 27, 2010) Neighbor Discovery Optimization for Low-power and Lossy=20 >> Networks >> >> However, the document as it passed WGLC still is focused on 6LoWPANs=20 >> (e.g., it contains specific support for 6COs). >> >> For both HC and ND, I don't think we properly discussed the attempted=20 >> 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=20 >> RFC 4944 doesn't have it, but in the 4 years since, the term has=20 >> gained some recognition.) Should there be another common marker? --=20 >> E.g., should we change over the whole documents (HC, ND) to LLN? --=20 >> Should we just refer to IEEE 802.15.4 in the title (no 6LoWPAN)? HC =3D= =20 >> Compression Format for IPv6 Datagrams over IEEE >> 802.15.4 > Networks >> ND =3D Neighbor Discovery Optimization for IEEE 802.15.4 Networks -- Or= =20 >> should we stick with 6LoWPAN in both title and body? -- If the=20 >> latter, what is an appropriate expansion of 6LoWPAN? Can we get rid=20 >> of the "Personal" in the expansion? -- IPv6 over Low power Wireless=20 >> Personal Area Networks [RFC4944] -- IPv6-based Low power Wireless=20 >> Personal Area Networks [RFC4944] -- IPv6 over Low-Power Wireless Area=20 >> Networks -- IPv6-based Low-power WPANs -- Other ideas? -- Whatever we=20 >> decide about the above: What is the relationship between the=20 >> well-known term 6LoWPAN and ROLL LLNs? >> >> Since 6LoWPAN-HC is waiting in the RFC editor queue, blocked for just=20 >> 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=20 >> 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan > _______________________________________________ 6lowpan mailing list =20 > 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan > _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From alexandru.petrescu@gmail.com Thu Jul 7 01:13:23 2011 Return-Path: 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 6FFEE21F8639 for <6lowpan@ietfa.amsl.com>; Thu, 7 Jul 2011 01:13:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.750, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_FR=0.35] 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 ou5si3og-vzM for <6lowpan@ietfa.amsl.com>; Thu, 7 Jul 2011 01:13:22 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 84EAA21F862F for <6lowpan@ietf.org>; Thu, 7 Jul 2011 01:13:21 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.2) with ESMTP id p678DILI022616 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 7 Jul 2011 10:13:18 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id p678DIgp027518; Thu, 7 Jul 2011 10:13:18 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [132.166.133.178] (is010173.intra.cea.fr [132.166.133.178]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id p678DIok009008; Thu, 7 Jul 2011 10:13:18 +0200 Message-ID: <4E156A9E.50902@gmail.com> Date: Thu, 07 Jul 2011 10:13:18 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Samita Chakrabarti References: <1BB75432-B4F7-4D30-BC0F-31369D11105C@tzi.org> <6A2A459175DABE4BB11DE2026AA50A5D04FAE351@XMB-AMS-107.cisco.com> <4E0DF567.1020207@gmail.com> <16D60F43CA0B724F8052D7E9323565D71E6717EA48@EUSAACMS0715.eamcs.ericsson.se> In-Reply-To: <16D60F43CA0B724F8052D7E9323565D71E6717EA48@EUSAACMS0715.eamcs.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "6lowpan@ietf.org" <6lowpan@ietf.org> 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 08:13:23 -0000 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 > > -----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 > From robert.cragie@gridmerge.com Thu Jul 7 05:22:19 2011 Return-Path: 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 5474921F85B4 for <6lowpan@ietfa.amsl.com>; Thu, 7 Jul 2011 05:22:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2] 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 Pf0MVDQJQAuU for <6lowpan@ietfa.amsl.com>; Thu, 7 Jul 2011 05:22:18 -0700 (PDT) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by ietfa.amsl.com (Postfix) with ESMTP id 0C3A221F86AA for <6lowpan@ietf.org>; Thu, 7 Jul 2011 05:22:18 -0700 (PDT) Received: from client-86-29-254-160.pete.adsl.virginmedia.com ([86.29.254.160] helo=[192.168.1.80]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) id 1Qenay-0002iy-9K for 6lowpan@ietf.org; Thu, 07 Jul 2011 13:22:16 +0100 Message-ID: <4E15A537.2090602@gridmerge.com> Date: Thu, 07 Jul 2011 13:23:19 +0100 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: 6lowpan@ietf.org References: <1BB75432-B4F7-4D30-BC0F-31369D11105C@tzi.org> <6A2A459175DABE4BB11DE2026AA50A5D04FAE351@XMB-AMS-107.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D04FAE351@XMB-AMS-107.cisco.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070500000501030606060308" X-Authenticated-As: robert.cragie@gridmerge.com Subject: Re: [6lowpan] Titles of 6LoWPAN RFCs X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 12:22:19 -0000 This is a cryptographically signed message in MIME format. --------------ms070500000501030606060308 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable +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=20 loWPAN is a reasonable, pronounceable abbreviation which implies=20 802.15.4 in the context of 802.15 but could mean other similar types of=20 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. > > ND does not have such a strong link to the MAC so there is no 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. > > 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 =3D Compression Format for IPv6 Datagrams over IEEE 802.15.4= > Networks >> ND =3D Neighbor Discovery Optimization for IEEE 802.15.4 Networ= ks >> -- 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 > --------------ms070500000501030606060308 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIREjCC BIowggNyoAMCAQICECf06hH0eobEbp27bqkXBwcwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UE BhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0w NTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMC VVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5l dHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVN NRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQy lbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXq vgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6 hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu 9mIwFIws6wIDAQABo4HhMIHeMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0G A1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/ BAUwAwEB/zB7BgNVHR8EdDByMDigNqA0hjJodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9BZGRU cnVzdEV4dGVybmFsQ0FSb290LmNybDA2oDSgMoYwaHR0cDovL2NybC5jb21vZG8ubmV0L0Fk ZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQAZ2IkRbyispgCi 54fBm5AD236hEv0e8+LwAamUVEJrmgnEoG3XkJIEA2Z5Q3H8+G+v23ZF4jcaPd3kWQR4rBz0 g0bzes9bhHIt5UbBuhgRKfPLSXmHPLptBZ2kbWhPrXIUNqi5sf2/z3/wpGqUNVCPz4FtVbHd WTBK322gnGQfSXzvNrv042n0+DmPWq1LhTq3Du3Tzw1EovsEv+QvcI4l+1pUBrPQxLxtjftz Mizpm4QkLdZ/kXpoAlAfDj9N6cz1u2fo3BwuO/xOzf4CjuOoEwqlJkRl6RDyTVKnrtw+ymsy XEFs/vVdoOr/0fqbhlhtPZZH5f4ulQTCAMyOofK7MIIGPjCCBSagAwIBAgIRALZcFI008b3q kGPLKBbwWBIwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEX MBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29y azEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMTAwODMwMDAwMDAw WhcNMTEwODMwMjM1OTU5WjCB5DE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQ RVJTT05BIE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9m IHVzZTogaHR0cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIw MDMgQ29tb2RvIExpbWl0ZWQxFjAUBgNVBAMTDVJvYmVydCBDcmFnaWUxKjAoBgkqhkiG9w0B CQEWG3JvYmVydC5jcmFnaWVAZ3JpZG1lcmdlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBALQCfpvU4Hd5YvAYACEbYRrbYd2HAm4Sz43wHJwynBBkq5GamqO/SYNrg1ut iDsDQqvWnt1cHgZb4N1FFbvLqV84A0f4xc+EtWTZNYn+lfUBIsgR3RNajFEHnsrXnZN6sPdw lObJ1ol4FUWnFPB/A7/liT7G+FmAB+DAc2iTCNjfxOVxhmKShY/b8ZxIkO4fN418cNxHtq1w gm4SRHIv7VJfgseNKQd5u55RHQEmPgN7aiSyIhvAK4H9Pm1msZrklIoSqGpIR0K7gMpVmPRF bWyoPEgAmGYXRwsdvmUkq8W2wCkr9HA5NNL0D74B+RhIus0gfUL6lgnQR/6y9F31eY0CAwEA AaOCAh0wggIZMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBRp GoTqjgTJPeVwG/HaXEXWnn/AGDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNV HSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1Ud IAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNv bW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2RvY2Eu Y29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRp Y2F0aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDov L2NydC5jb21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC5jb21vZG9jYS5jb20wJgYDVR0RBB8wHYEbcm9iZXJ0LmNyYWdpZUBncmlkbWVy Z2UuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQA3I0iUCoFSHw/yM7Ra4cdmKkfZirA7N12pCneI VKHrpx4LJImjCEGNinH6G+PDrs632O96zXzaGqq+S2cA3lX5TJ2XdKz3EwPawB6uZf6sHUrW t5NMbwbotDQLTq0gXW6guL4ICyrmb6EdqO5km8UkgWR7lSzm8fxORPg+X41gu33zb6/cv7hV 3gmBbDPh3PVTyGfnAGOyUBSRCvzbrYtkByCMXUfdTdrx7jV1iD0TjxTJe8vJbTv3zjcIcTHG NnR+CZAx+qXTczLc8pL7DtDXokR5zZUuCgPGg/UWgUfBTUB6vibrAtrX9danRwaR61QCu3R6 HSg520a9rfVXa1NqMIIGPjCCBSagAwIBAgIRALZcFI008b3qkGPLKBbwWBIwDQYJKoZIhvcN AQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtl IENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDov L3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRo ZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMTAwODMwMDAwMDAwWhcNMTEwODMwMjM1OTU5WjCB 5DE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05BIE5PVCBWQUxJREFU RUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0cDovL3d3dy5j b21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExpbWl0ZWQx FjAUBgNVBAMTDVJvYmVydCBDcmFnaWUxKjAoBgkqhkiG9w0BCQEWG3JvYmVydC5jcmFnaWVA Z3JpZG1lcmdlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALQCfpvU4Hd5 YvAYACEbYRrbYd2HAm4Sz43wHJwynBBkq5GamqO/SYNrg1utiDsDQqvWnt1cHgZb4N1FFbvL qV84A0f4xc+EtWTZNYn+lfUBIsgR3RNajFEHnsrXnZN6sPdwlObJ1ol4FUWnFPB/A7/liT7G +FmAB+DAc2iTCNjfxOVxhmKShY/b8ZxIkO4fN418cNxHtq1wgm4SRHIv7VJfgseNKQd5u55R HQEmPgN7aiSyIhvAK4H9Pm1msZrklIoSqGpIR0K7gMpVmPRFbWyoPEgAmGYXRwsdvmUkq8W2 wCkr9HA5NNL0D74B+RhIus0gfUL6lgnQR/6y9F31eY0CAwEAAaOCAh0wggIZMB8GA1UdIwQY MBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBRpGoTqjgTJPeVwG/HaXEXWnn/A GDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYL KwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQEC AQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNV HR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL1VUTi1VU0VSRmlyc3Qt Q2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBIoEaGRGh0dHA6Ly9jcmwuY29t b2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3Js MGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5jb21vZG9jYS5jb20v VVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5j b20wJgYDVR0RBB8wHYEbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMA0GCSqGSIb3DQEB BQUAA4IBAQA3I0iUCoFSHw/yM7Ra4cdmKkfZirA7N12pCneIVKHrpx4LJImjCEGNinH6G+PD rs632O96zXzaGqq+S2cA3lX5TJ2XdKz3EwPawB6uZf6sHUrWt5NMbwbotDQLTq0gXW6guL4I Cyrmb6EdqO5km8UkgWR7lSzm8fxORPg+X41gu33zb6/cv7hV3gmBbDPh3PVTyGfnAGOyUBSR CvzbrYtkByCMXUfdTdrx7jV1iD0TjxTJe8vJbTv3zjcIcTHGNnR+CZAx+qXTczLc8pL7DtDX okR5zZUuCgPGg/UWgUfBTUB6vibrAtrX9danRwaR61QCu3R6HSg520a9rfVXa1NqMYIEYDCC BFwCAQEwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBM YWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0 cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBB dXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQC2XBSNNPG96pBjyygW8FgSMAkGBSsOAwIaBQCg ggJwMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDcwNzEy MjMxOVowIwYJKoZIhvcNAQkEMRYEFGufXxfyLO4ebgprYkrFvW2bk+KOMF8GCSqGSIb3DQEJ DzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG 9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB1QYJKwYBBAGCNxAEMYHHMIHEMIGu MQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4w HAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNl cnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRp b24gYW5kIEVtYWlsAhEAtlwUjTTxveqQY8soFvBYEjCB1wYLKoZIhvcNAQkQAgsxgceggcQw ga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkx HjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51 c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgRW1haWwCEQC2XBSNNPG96pBjyygW8FgSMA0GCSqGSIb3DQEBAQUABIIBAC4A 6w2D8udpb4q40DIAXbUmsoz+qkpZyg0ff92ATD4P0k9ldJwGl6air5mXDgKg1dS9M5RUJmB8 r1mNIJjCgc1Xyzk7sR/hrw2bT9ig8nhvNQrRyP8687MesJ7C+BY+sHWaRjyOeCvMTEIctsld t2rbwdH1Q1HZkDgMvAGckySiPcYe3vAUb7V69FSYRa7qh5Dcc1+tubmb4htFTbWddOVkY+Tf 38FIxjmnq0weBmO7Q7d0aa+ERsy+hF0fz59lDbDQMuBUR8ATbt/JHAHnPS5EVVTbGcp++ZHy BD/Cwcx8qr346WAyP5h42OlC08AP+Zjxa3I+a7NRJ9soJdDOhyYAAAAAAAA= --------------ms070500000501030606060308-- From alexandru.petrescu@gmail.com Thu Jul 7 07:29:34 2011 Return-Path: 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 46D5C11E8083 for <6lowpan@ietfa.amsl.com>; Thu, 7 Jul 2011 07:29:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.582 X-Spam-Level: X-Spam-Status: No, score=-3.582 tagged_above=-999 required=5 tests=[AWL=0.667, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_FR=0.35] 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 pnrx7cugSoIj for <6lowpan@ietfa.amsl.com>; Thu, 7 Jul 2011 07:29:33 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 7B9D311E8082 for <6lowpan@ietf.org>; Thu, 7 Jul 2011 07:29:32 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.2) with ESMTP id p67ETVea015207 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <6lowpan@ietf.org>; Thu, 7 Jul 2011 16:29:31 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id p67ETUGJ017968 for <6lowpan@ietf.org>; Thu, 7 Jul 2011 16:29:31 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [132.166.133.178] (is010173.intra.cea.fr [132.166.133.178]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id p67ETUi5018083 for <6lowpan@ietf.org>; Thu, 7 Jul 2011 16:29:30 +0200 Message-ID: <4E15C2CA.3050609@gmail.com> Date: Thu, 07 Jul 2011 16:29:30 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: 6lowpan@ietf.org References: <1BB75432-B4F7-4D30-BC0F-31369D11105C@tzi.org> <6A2A459175DABE4BB11DE2026AA50A5D04FAE351@XMB-AMS-107.cisco.com> <4E15A537.2090602@gridmerge.com> In-Reply-To: <4E15A537.2090602@gridmerge.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 14:29:34 -0000 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 > > 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. >> >> ND does not have such a strong link to the MAC so there is no >> 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. >> >> 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 From jonhui@cisco.com Thu Jul 7 10:38:55 2011 Return-Path: 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 816481F0C57 for <6lowpan@ietfa.amsl.com>; Thu, 7 Jul 2011 10:38:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2] 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 f51nzY+u3Hgj for <6lowpan@ietfa.amsl.com>; Thu, 7 Jul 2011 10:38:54 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 693CE1F0C44 for <6lowpan@ietf.org>; Thu, 7 Jul 2011 10:38:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jonhui@cisco.com; l=6174; q=dns/txt; s=iport; t=1310060334; x=1311269934; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=/Ayk6S9Pk8SWQ9l2Afnld1JqSHeakymlJOB0YfGPcgo=; b=Axb1X+asrvcDcErhe3qh7lIekZQcfvxMHD69YytWmilswFVaaBmWpLnH yA+yGImrEW1eoP+t5qf28qGoH3sQxQEiykeR87g3YSOgizZDHWwvaMOqN DTLvZ8udse8/sd9YfBMNtpU6Px6ikvZjT0IBeW2Vz3Cy8jtvDGahblVvX U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAGjuFU6rRDoH/2dsb2JhbABTpzV3iHukZJ16hjgEh0mKfZBh X-IronPort-AV: E=Sophos;i="4.65,494,1304294400"; d="scan'208";a="749101" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-6.cisco.com with ESMTP; 07 Jul 2011 17:38:53 +0000 Received: from sjc-vpn5-1566.cisco.com (sjc-vpn5-1566.cisco.com [10.21.94.30]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p67Hcr8T013047; Thu, 7 Jul 2011 17:38:53 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Jonathan Hui In-Reply-To: <1BB75432-B4F7-4D30-BC0F-31369D11105C@tzi.org> Date: Thu, 7 Jul 2011 10:39:03 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1BB75432-B4F7-4D30-BC0F-31369D11105C@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.1084) Cc: 6lowpan WG <6lowpan@ietf.org> 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 17:38:55 -0000 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. >=20 > The exposition of the problem takes a couple of paragraphs, so bear > with me, please. >=20 > 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. >=20 > One issue with that is that, strictly speaking, 6LoWPAN would require > a double expansion in an RFC title as in >=20 > 6LoWPAN (IPv6 over Low Power WPAN (Wireless Personal Area Networks)) >=20 > 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). >=20 > 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. >=20 > In the recent history of 6LoWPAN-HC being fixed up to address WGLC > comments, there was a silent title change. >=20 > 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) >=20 > 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. >=20 > 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.) >=20 > 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: >=20 > ND-08: (February 1, 2010) > 6LoWPAN Neighbor Discovery > ND-09: (April 27, 2010) > Neighbor Discovery Optimization for Low-power and Lossy Networks >=20 > However, the document as it passed WGLC still is focused on 6LoWPANs > (e.g., it contains specific support for 6COs). >=20 > For both HC and ND, I don't think we properly discussed the attempted > title changes in the WG. >=20 > So what are the specific issues to be decided? > I see at least: >=20 > -- 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 =3D Compression Format for IPv6 Datagrams over IEEE 802.15.4 = Networks > ND =3D 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? >=20 > 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. >=20 > Gruesse, Carsten >=20 > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan From robert.cragie@gridmerge.com Thu Jul 7 14:52:51 2011 Return-Path: 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 6A3329E803F for <6lowpan@ietfa.amsl.com>; Thu, 7 Jul 2011 14:52:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2] 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 XTicb50lCZed for <6lowpan@ietfa.amsl.com>; Thu, 7 Jul 2011 14:52:50 -0700 (PDT) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by ietfa.amsl.com (Postfix) with ESMTP id CD02E9E8037 for <6lowpan@ietf.org>; Thu, 7 Jul 2011 14:52:49 -0700 (PDT) Received: from client-86-29-254-160.pete.adsl.virginmedia.com ([86.29.254.160] helo=[192.168.1.80]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) id 1QewV4-0004N6-7m for 6lowpan@ietf.org; Thu, 07 Jul 2011 22:52:46 +0100 Message-ID: <4E162AED.8040502@gridmerge.com> Date: Thu, 07 Jul 2011 22:53:49 +0100 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: 6lowpan@ietf.org References: <1BB75432-B4F7-4D30-BC0F-31369D11105C@tzi.org> <6A2A459175DABE4BB11DE2026AA50A5D04FAE351@XMB-AMS-107.cisco.com> <4E15A537.2090602@gridmerge.com> <4E15C2CA.3050609@gmail.com> In-Reply-To: <4E15C2CA.3050609@gmail.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060003030606020202090403" X-Authenticated-As: robert.cragie@gridmerge.com Subject: Re: [6lowpan] Titles of 6LoWPAN RFCs X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 21:52:51 -0000 This is a cryptographically signed message in MIME format. --------------ms060003030606020202090403 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Alex, I don't think you're reading what I'm writing. As I said, WPAN was=20 chosen by the IEEE for the 802.15 WG. The 802.15 WG is about wireless,=20 hence the 'W'. You assume 'personal' means 'wearable', however the IEEE=20 actually use 'body' (as in BAN, body area network) for this. I think=20 'personal' is simply meant to be the next down in scope from 'local',=20 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=20 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 . We could go on = forever. On a more serious note, I agree with Jonathan about being more precise=20 for HC as that is specific. Of his three suggestions, my preference=20 would be "Compression Format for IPv6 Datagrams over IEEE 802.15.4-based = Networks". Robert On 07/07/2011 3:29 PM, Alexandru Petrescu wrote: > Le 07/07/2011 14:23, Robert Cragie a =E9crit : >> +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 > >> >> 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. >>> >>> ND does not have such a strong link to the MAC so there is no >>> 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. >>> >>> 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 =3D Compression Format for IPv6 Datagrams over >>>> IEEE 802.15.4 >>> Networks >>>> ND =3D 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 > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > --------------ms060003030606020202090403 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIREjCC BIowggNyoAMCAQICECf06hH0eobEbp27bqkXBwcwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UE BhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0w NTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMC VVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5l dHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVN NRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQy lbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXq vgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6 hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu 9mIwFIws6wIDAQABo4HhMIHeMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0G A1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/ BAUwAwEB/zB7BgNVHR8EdDByMDigNqA0hjJodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9BZGRU cnVzdEV4dGVybmFsQ0FSb290LmNybDA2oDSgMoYwaHR0cDovL2NybC5jb21vZG8ubmV0L0Fk ZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQAZ2IkRbyispgCi 54fBm5AD236hEv0e8+LwAamUVEJrmgnEoG3XkJIEA2Z5Q3H8+G+v23ZF4jcaPd3kWQR4rBz0 g0bzes9bhHIt5UbBuhgRKfPLSXmHPLptBZ2kbWhPrXIUNqi5sf2/z3/wpGqUNVCPz4FtVbHd WTBK322gnGQfSXzvNrv042n0+DmPWq1LhTq3Du3Tzw1EovsEv+QvcI4l+1pUBrPQxLxtjftz Mizpm4QkLdZ/kXpoAlAfDj9N6cz1u2fo3BwuO/xOzf4CjuOoEwqlJkRl6RDyTVKnrtw+ymsy XEFs/vVdoOr/0fqbhlhtPZZH5f4ulQTCAMyOofK7MIIGPjCCBSagAwIBAgIRALZcFI008b3q kGPLKBbwWBIwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEX MBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29y azEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMTAwODMwMDAwMDAw WhcNMTEwODMwMjM1OTU5WjCB5DE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQ RVJTT05BIE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9m IHVzZTogaHR0cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIw MDMgQ29tb2RvIExpbWl0ZWQxFjAUBgNVBAMTDVJvYmVydCBDcmFnaWUxKjAoBgkqhkiG9w0B CQEWG3JvYmVydC5jcmFnaWVAZ3JpZG1lcmdlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBALQCfpvU4Hd5YvAYACEbYRrbYd2HAm4Sz43wHJwynBBkq5GamqO/SYNrg1ut iDsDQqvWnt1cHgZb4N1FFbvLqV84A0f4xc+EtWTZNYn+lfUBIsgR3RNajFEHnsrXnZN6sPdw lObJ1ol4FUWnFPB/A7/liT7G+FmAB+DAc2iTCNjfxOVxhmKShY/b8ZxIkO4fN418cNxHtq1w gm4SRHIv7VJfgseNKQd5u55RHQEmPgN7aiSyIhvAK4H9Pm1msZrklIoSqGpIR0K7gMpVmPRF bWyoPEgAmGYXRwsdvmUkq8W2wCkr9HA5NNL0D74B+RhIus0gfUL6lgnQR/6y9F31eY0CAwEA AaOCAh0wggIZMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBRp GoTqjgTJPeVwG/HaXEXWnn/AGDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNV HSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1Ud IAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNv bW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2RvY2Eu Y29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRp Y2F0aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDov L2NydC5jb21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC5jb21vZG9jYS5jb20wJgYDVR0RBB8wHYEbcm9iZXJ0LmNyYWdpZUBncmlkbWVy Z2UuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQA3I0iUCoFSHw/yM7Ra4cdmKkfZirA7N12pCneI VKHrpx4LJImjCEGNinH6G+PDrs632O96zXzaGqq+S2cA3lX5TJ2XdKz3EwPawB6uZf6sHUrW t5NMbwbotDQLTq0gXW6guL4ICyrmb6EdqO5km8UkgWR7lSzm8fxORPg+X41gu33zb6/cv7hV 3gmBbDPh3PVTyGfnAGOyUBSRCvzbrYtkByCMXUfdTdrx7jV1iD0TjxTJe8vJbTv3zjcIcTHG NnR+CZAx+qXTczLc8pL7DtDXokR5zZUuCgPGg/UWgUfBTUB6vibrAtrX9danRwaR61QCu3R6 HSg520a9rfVXa1NqMIIGPjCCBSagAwIBAgIRALZcFI008b3qkGPLKBbwWBIwDQYJKoZIhvcN AQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtl IENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDov L3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRo ZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMTAwODMwMDAwMDAwWhcNMTEwODMwMjM1OTU5WjCB 5DE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05BIE5PVCBWQUxJREFU RUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0cDovL3d3dy5j b21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExpbWl0ZWQx FjAUBgNVBAMTDVJvYmVydCBDcmFnaWUxKjAoBgkqhkiG9w0BCQEWG3JvYmVydC5jcmFnaWVA Z3JpZG1lcmdlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALQCfpvU4Hd5 YvAYACEbYRrbYd2HAm4Sz43wHJwynBBkq5GamqO/SYNrg1utiDsDQqvWnt1cHgZb4N1FFbvL qV84A0f4xc+EtWTZNYn+lfUBIsgR3RNajFEHnsrXnZN6sPdwlObJ1ol4FUWnFPB/A7/liT7G +FmAB+DAc2iTCNjfxOVxhmKShY/b8ZxIkO4fN418cNxHtq1wgm4SRHIv7VJfgseNKQd5u55R HQEmPgN7aiSyIhvAK4H9Pm1msZrklIoSqGpIR0K7gMpVmPRFbWyoPEgAmGYXRwsdvmUkq8W2 wCkr9HA5NNL0D74B+RhIus0gfUL6lgnQR/6y9F31eY0CAwEAAaOCAh0wggIZMB8GA1UdIwQY MBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBRpGoTqjgTJPeVwG/HaXEXWnn/A GDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYL KwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQEC AQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNV HR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL1VUTi1VU0VSRmlyc3Qt Q2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBIoEaGRGh0dHA6Ly9jcmwuY29t b2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3Js MGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5jb21vZG9jYS5jb20v VVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5j b20wJgYDVR0RBB8wHYEbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMA0GCSqGSIb3DQEB BQUAA4IBAQA3I0iUCoFSHw/yM7Ra4cdmKkfZirA7N12pCneIVKHrpx4LJImjCEGNinH6G+PD rs632O96zXzaGqq+S2cA3lX5TJ2XdKz3EwPawB6uZf6sHUrWt5NMbwbotDQLTq0gXW6guL4I Cyrmb6EdqO5km8UkgWR7lSzm8fxORPg+X41gu33zb6/cv7hV3gmBbDPh3PVTyGfnAGOyUBSR CvzbrYtkByCMXUfdTdrx7jV1iD0TjxTJe8vJbTv3zjcIcTHGNnR+CZAx+qXTczLc8pL7DtDX okR5zZUuCgPGg/UWgUfBTUB6vibrAtrX9danRwaR61QCu3R6HSg520a9rfVXa1NqMYIEYDCC BFwCAQEwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBM YWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0 cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBB dXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQC2XBSNNPG96pBjyygW8FgSMAkGBSsOAwIaBQCg ggJwMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDcwNzIx NTM0OVowIwYJKoZIhvcNAQkEMRYEFNQdRyHuT7knrO0cDEYe2m2iPbOrMF8GCSqGSIb3DQEJ DzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG 9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB1QYJKwYBBAGCNxAEMYHHMIHEMIGu MQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4w HAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNl cnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRp b24gYW5kIEVtYWlsAhEAtlwUjTTxveqQY8soFvBYEjCB1wYLKoZIhvcNAQkQAgsxgceggcQw ga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkx HjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51 c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgRW1haWwCEQC2XBSNNPG96pBjyygW8FgSMA0GCSqGSIb3DQEBAQUABIIBAD1k f5vtps+QNtboeOypikwmRTMmW3VtuzRHrmNEimotVjZt7fBf4caYcJfnlds/yTCucMTGP0oO E5vNiGrzNa1GnQXOzgcEyRB0n+oqtTDR85qAfRr2wh98wbUXN7RGGcFJ5QJZoxke/5oq1Cp7 Ry3ThBubGr5g1TDUxTaAx65FoGdV0TtVMO3MAwVmBRgFtUa+JkntDXEWjSgODNPKvF0v9YxW AAWDnL2BHE3QhEr4oLGn3mTx8wyfF/Qj6OFcruH9MdNMBWo/Yiqreb0OAgothn2fNaXvmolP k/R4vdINMz/HPsFsf0bzTF4g04aYwhP7GQi+s8TbaaW6NFAPymIAAAAAAAA= --------------ms060003030606020202090403-- From alexandru.petrescu@gmail.com Fri Jul 8 00:30:07 2011 Return-Path: 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 4E28121F87BB for <6lowpan@ietfa.amsl.com>; Fri, 8 Jul 2011 00:30:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.649 X-Spam-Level: X-Spam-Status: No, score=-3.649 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_FR=0.35] 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 qQGa8nVnsDNX for <6lowpan@ietfa.amsl.com>; Fri, 8 Jul 2011 00:30:06 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.144]) by ietfa.amsl.com (Postfix) with ESMTP id BA05921F86DE for <6lowpan@ietf.org>; Fri, 8 Jul 2011 00:30:05 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.2) with ESMTP id p687U3Gk022457 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 8 Jul 2011 09:30:03 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id p687U3wh027406; Fri, 8 Jul 2011 09:30:03 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [132.166.133.178] (is010173.intra.cea.fr [132.166.133.178]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id p687U3wB007348; Fri, 8 Jul 2011 09:30:03 +0200 Message-ID: <4E16B1FB.3010606@gmail.com> Date: Fri, 08 Jul 2011 09:30:03 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: 6lowpan@ietf.org References: <1BB75432-B4F7-4D30-BC0F-31369D11105C@tzi.org> <6A2A459175DABE4BB11DE2026AA50A5D04FAE351@XMB-AMS-107.cisco.com> <4E15A537.2090602@gridmerge.com> <4E15C2CA.3050609@gmail.com> <4E162AED.8040502@gridmerge.com> In-Reply-To: <4E162AED.8040502@gridmerge.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 07:30:07 -0000 Le 07/07/2011 23:53, Robert Cragie a écrit : > 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'). 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 . 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 > > Robert > > On 07/07/2011 3:29 PM, Alexandru Petrescu wrote: >> 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 >> >>> >>> 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. >>>> >>>> ND does not have such a strong link to the MAC so there is no >>>> 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. >>>> >>>> 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 >> >> _______________________________________________ 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 From alexandru.petrescu@gmail.com Fri Jul 8 00:50:31 2011 Return-Path: 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 8B20521F86B3 for <6lowpan@ietfa.amsl.com>; Fri, 8 Jul 2011 00:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.704 X-Spam-Level: X-Spam-Status: No, score=-3.704 tagged_above=-999 required=5 tests=[AWL=0.545, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_FR=0.35] 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 L5C5lMpUssSB for <6lowpan@ietfa.amsl.com>; Fri, 8 Jul 2011 00:50:30 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.144]) by ietfa.amsl.com (Postfix) with ESMTP id 5794621F86F5 for <6lowpan@ietf.org>; Fri, 8 Jul 2011 00:50:30 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.2) with ESMTP id p687oTPB030803 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 8 Jul 2011 09:50:29 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id p687oSis003480; Fri, 8 Jul 2011 09:50:28 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [132.166.133.178] (is010173.intra.cea.fr [132.166.133.178]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id p687oRV6019279; Fri, 8 Jul 2011 09:50:27 +0200 Message-ID: <4E16B6C2.3080704@gmail.com> Date: Fri, 08 Jul 2011 09:50:26 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: 6lowpan@ietf.org References: <1BB75432-B4F7-4D30-BC0F-31369D11105C@tzi.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 07:50:31 -0000 Le 07/07/2011 19:39, Jonathan Hui a écrit : > > 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" 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 > > -- > 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 > From pthubert@cisco.com Fri Jul 8 01:11:35 2011 Return-Path: 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 8AD4621F8777 for <6lowpan@ietfa.amsl.com>; Fri, 8 Jul 2011 01:11:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.266 X-Spam-Level: X-Spam-Status: No, score=-12.266 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_HI=-8] 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 HGGPLf7t2x4f for <6lowpan@ietfa.amsl.com>; Fri, 8 Jul 2011 01:11:34 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id EBC3221F875B for <6lowpan@ietf.org>; Fri, 8 Jul 2011 01:11:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=6899; q=dns/txt; s=iport; t=1310112694; x=1311322294; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=gdNfHGCaXrE8oNqBcachgBa9J5IRHrQZkzf2LaNq9ms=; b=f4a+sa15TclRu5wdtIVEeBhRcn2/ol8q7WSbIWD9EpbOh+lSSwul3Rod Oy/y8oROheq2Pszfr/r6uuk/4cDWbCzjCtSe/ZXDxrku1j5DWHzCPNKiM WQLkY9za0cZ9tj9vJogU3ytyPZhhTRIRWdwyaiRZx8y+qVc8fhQgHn0zl I=; X-IronPort-AV: E=Sophos;i="4.65,498,1304294400"; d="scan'208";a="41190372" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 08 Jul 2011 08:11:32 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p688BXNU017944; Fri, 8 Jul 2011 08:11:33 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 8 Jul 2011 10:11:33 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 8 Jul 2011 10:11:30 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0506E8A9@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] Titles of 6LoWPAN RFCs Thread-Index: Acw8zMN6S23bpYzjSfy7DrPGuhX3CAAeclRQ References: <1BB75432-B4F7-4D30-BC0F-31369D11105C@tzi.org> From: "Pascal Thubert (pthubert)" To: "Jonathan Hui" , "Carsten Bormann" X-OriginalArrivalTime: 08 Jul 2011 08:11:33.0006 (UTC) FILETIME=[A61152E0:01CC3D46] Cc: 6lowpan WG <6lowpan@ietf.org> 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 08:11:35 -0000 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: > "Compression Format for IPv6 Datagrams over IEEE 802.15.4-based > Networks" > or > "Compression Format for IPv6 Datagrams in IEEE 802.15.4 Frames" > Either works for me. I think the latter is even better. Pascal > -----Original Message----- > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On > Behalf Of Jonathan Hui > Sent: Thursday, July 07, 2011 7:39 PM > To: Carsten Bormann > Cc: 6lowpan WG > Subject: Re: [6lowpan] Titles of 6LoWPAN RFCs >=20 >=20 > 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. >=20 > Note that RFC 4944's title is "Transmission of IPv6 Packets over IEEE 802.15.4 > Networks". draft-ietf-6lowpan-hc updates RFC 4944. >=20 > Following that view, we could have: > "Compression Format for IPv6 Datagrams over IEEE 802.15.4 Networks". >=20 >=20 > -- > Jonathan Hui >=20 > On Jun 29, 2011, at 4:20 AM, Carsten Bormann wrote: >=20 > > 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 =3D Compression Format for IPv6 Datagrams over IEEE 802.15.4 > Networks > > ND =3D 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 >=20 > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan From geoff.ietf@mulligan.com Mon Jul 11 09:07:39 2011 Return-Path: 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 6715421F8C8C for <6lowpan@ietfa.amsl.com>; Mon, 11 Jul 2011 09:07:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=2.300, BAYES_00=-2.599, GB_I_LETTER=-2] 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 qeNicF4LrA4K for <6lowpan@ietfa.amsl.com>; Mon, 11 Jul 2011 09:07:38 -0700 (PDT) Received: from server2.coslabs.com (server2.coslabs.com [64.111.18.234]) by ietfa.amsl.com (Postfix) with ESMTP id 68AC521F8D26 for <6lowpan@ietf.org>; Mon, 11 Jul 2011 09:07:35 -0700 (PDT) Received: from grab.coslabs.com (mail.coslabs.com [199.233.92.34]) by server2.coslabs.com (Postfix) with ESMTP id A1FF1184BD; Mon, 11 Jul 2011 10:07:35 -0600 (MDT) Received: from [199.233.92.6] (unknown [199.233.92.6]) by grab.coslabs.com (Postfix) with ESMTP id 1065916030B; Mon, 11 Jul 2011 10:07:32 -0600 (MDT) From: Geoff Mulligan To: "Pascal Thubert (pthubert)" In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D0506E8A9@XMB-AMS-107.cisco.com> References: <1BB75432-B4F7-4D30-BC0F-31369D11105C@tzi.org> <6A2A459175DABE4BB11DE2026AA50A5D0506E8A9@XMB-AMS-107.cisco.com> Content-Type: text/plain; charset="UTF-8" Date: Mon, 11 Jul 2011 10:07:33 -0600 Message-ID: <1310400453.3910.0.camel@d430> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: 7bit Cc: Carsten Bormann , 6lowpan WG <6lowpan@ietf.org> 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 16:07:39 -0000 I think that either would be fine. geoff On Fri, 2011-07-08 at 10:11 +0200, Pascal Thubert (pthubert) wrote: > 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: > > "Compression Format for IPv6 Datagrams over IEEE 802.15.4-based > > Networks" > > or > > "Compression Format for IPv6 Datagrams in IEEE 802.15.4 Frames" > > > > Either works for me. I think the latter is even better. > > Pascal > > > -----Original Message----- > > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On > > Behalf Of Jonathan Hui > > Sent: Thursday, July 07, 2011 7:39 PM > > To: Carsten Bormann > > Cc: 6lowpan WG > > Subject: Re: [6lowpan] Titles of 6LoWPAN RFCs > > > > > > 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". > > > > > > -- > > 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 > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan From sakane@tanu.org Thu Jul 14 06:54:14 2011 Return-Path: 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 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> In-Reply-To: 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: , List-Archive: List-Post: List-Help: List-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 From jari.arkko@piuha.net Fri Jul 15 07:02:34 2011 Return-Path: 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 5375321F8767; Fri, 15 Jul 2011 07:02:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.395 X-Spam-Level: X-Spam-Status: No, score=-102.395 tagged_above=-999 required=5 tests=[AWL=0.204, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 Xv954COrPIaP; Fri, 15 Jul 2011 07:02:34 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id C025121F8766; Fri, 15 Jul 2011 07:02:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 0392A2CEFF; Fri, 15 Jul 2011 17:02:33 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pVFpHoBU8rEI; Fri, 15 Jul 2011 17:02:32 +0300 (EEST) Received: from [IPv6:::1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 1C17D2CC4B; Fri, 15 Jul 2011 17:02:32 +0300 (EEST) Message-ID: <4E204877.8040108@piuha.net> Date: Fri, 15 Jul 2011 17:02:31 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: core , lwip@ietf.org, roll@ietf.org, 6lowpan@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [6lowpan] Internet of Things Hacking Meet 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 14:02:34 -0000 We would like to invite interested implementors for an informal session to interop test, play & demo, further develop your Things and for a general chat with other implementors. This is not a working group session or place to run presentations. If you happen to be around at the time and have some gear to bring or software on your laptop, do join us and maybe something interesting will come out of it. The event is intended for people implementing something around the Internet of Things space. For instance, I am personally interested in home networking and automation and will bring some COAP, IPv6, and 1-wire stuff, but other people are probably interested in other areas and protocols as well. We understand that this is a late announcement, and everyone has lots of other things on their agenda as well. For that purpose Hannes and I have reserved two nights to make it a bit more likely that people can drop by. The times are Saturday, July 23rd, 5PM to 8PM and Sunday, July 24th, 7PM to 9PM. Exact location is to be announced later, but it is in the IETF meeting hotel in Quebec City. Jari Arkko Hannes Tschofenig From zach@sensinode.com Sun Jul 17 23:39:16 2011 Return-Path: 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 3175221F8B17 for <6lowpan@ietfa.amsl.com>; Sun, 17 Jul 2011 23:39:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.382 X-Spam-Level: X-Spam-Status: No, score=-3.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 Dkd7jdKe8Nu5 for <6lowpan@ietfa.amsl.com>; Sun, 17 Jul 2011 23:39:14 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id ECB2721F8AF3 for <6lowpan@ietf.org>; Sun, 17 Jul 2011 23:39:12 -0700 (PDT) Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id p6I6d5up025521 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 18 Jul 2011 09:39:08 +0300 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-590--196018149; protocol="application/pkcs7-signature"; micalg=sha1 From: Zach Shelby In-Reply-To: <4E1EF4F8.7070308@tanu.org> Date: Mon, 18 Jul 2011 09:39:07 +0300 Message-Id: <1C800535-400E-43DA-B350-9C45D752F028@sensinode.com> References: <1BB75432-B4F7-4D30-BC0F-31369D11105C@tzi.org> <4E1EF4F8.7070308@tanu.org> To: Shoichi Sakane X-Mailer: Apple Mail (2.1084) Cc: 6lowpan <6lowpan@ietf.org> 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 06:39:16 -0000 --Apple-Mail-590--196018149 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 14, 2011, at 4:54 PM, Shoichi Sakane wrote: >> "Compression Format for IPv6 Datagrams over IEEE 802.15.4-based = Networks" >> or >> "Compression Format for IPv6 Datagrams in IEEE 802.15.4 Frames" >=20 > "IEEE 802.15.4-based Networks" makes sense to me. +1 --=20 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 --Apple-Mail-590--196018149 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKGzCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFRzCCBC+gAwIBAgIQan0RUwdo1sLDyX/9 fFJOUTANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTEwMDgxMDAwMDAwMFoXDTExMDgxMDIzNTk1OVowggEQMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC1phY2ggU2hl bGJ5MSEwHwYJKoZIhvcNAQkBFhJ6YWNoQHNlbnNpbm9kZS5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQCp7y7xWjidkiLHBnXP0MF+ZApAJC4Ef9cZCDtcNI55c7D78XMODsUyGxhH i5bnZQIf09tFuXl+088/VS7qgyrxo58QXpwmA7tP22bHVGb0asnxFZ28cnIvkZBcFaBgfPdi92Pb 6PL87S1bQqjw0CxXuGEs4VJtLKSejLVEYbs7CtkKMC/rfJixp3ytJ4rNh5U/XD/B2pM85DYmssto GkoXFwTwNB0HqNvGF9LN7D9JohmGkwo/FzqCZilf5CoFxM83xLHzbjPoDhZeXi/ygSiTF0eOC5ja 5vMFNyk6a+G8WlmxsUPqF73Lb1boJVODLKKDCu7wfk5ORoOUsA2YTFS9AgMBAAGjgcwwgckwCQYD VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBALA0uBctOXHWFO4I 2m3Ldf6Ui26jWIeYDAZ3Y12V3h8lU25RWegX4MwRGm0NcZvdX/jHlhGmvkbAegvYN3WUH9XNxRGf nXzVvK8oXChM23ET2b/g2zEsmimoDvsjvONV2vXRIPF1xMuKeWL/PsNiRKnq+jTbSOdqh7k4Rp8W PKfNjOGIRjYYHDB0O84i+JoSJKSzQp5SWpVG2vVIGLFG9vVxVjY65lqmqoxRIFRbtO7Qi/E4xxmm nRP75n1yAm7QOt+jCqJ8mCxQ0G/damNIHRxYJd0QNavACz34gdLmwEa88emIXscqqqxTyIj+jdIn VVOFE7PUo6rrAldWaGke1TYxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQL EzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIElu ZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMAkGBSsOAwIaBQCg ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDcxODA2Mzkw N1owIwYJKoZIhvcNAQkEMRYEFCArRhExxk+DDeCFrJqp5isFE9AEMIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBADaY8gl0GDk//XdOyNs1WdNF3WQTy9RosEGwy/4WBXAIzPXAcoAanXXA fHUI68urHRzv85+Z0nHvNonud+iJHeITlkHsE+A3QU7hOZhWy3Iw51ZRwVbZjrnWWhiq8wLnpNqK S8WLy6u1AGlzBX89D0F6S8IEq4k0bNecGJGurKMzGXx8H55RqONbzBZj3+HqXsjgJQnwjuJEAPlD LQf/Euptor/PsjUC9HHTnYz1ifu8wl/DzE2M15XSs4Eqi5w2Z1kL6gEEmBl64aTSO635vhJOns4f IB71iV3ATjY3xBz3Qusmg8kTnDeCaO85aVGhtWUP29a0Nlp6WMTTRBGu2VkAAAAAAAA= --Apple-Mail-590--196018149-- From pthubert@cisco.com Fri Jul 22 10:59:36 2011 Return-Path: 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 A03C121F8B50 for <6lowpan@ietfa.amsl.com>; Fri, 22 Jul 2011 10:59:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.349 X-Spam-Level: X-Spam-Status: No, score=-11.349 tagged_above=-999 required=5 tests=[AWL=-0.750, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 byP6CuxwJEV8 for <6lowpan@ietfa.amsl.com>; Fri, 22 Jul 2011 10:59:35 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 94EB721F8B4F for <6lowpan@ietf.org>; Fri, 22 Jul 2011 10:59:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=958; q=dns/txt; s=iport; t=1311357575; x=1312567175; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to:cc; bh=cptTvBPS8q7E392/kpNFUdv/SzN/62el+Hv9V5FdJeg=; b=T4TgM14W3AoNgUe0sYrmLo9qCNwVwZ6hcRqecGn9K+NREhl2NkrgcXPG PlwgxyVnwornW37UPW1NeS6a/4h8TdnIXZJ9fhbKr5keM8tRNezTtMlbY FEVWm0DLcQuUee8+XIDnHEJ4FjD279x6eQ2vl0QcyzO87P8gBvCOsl5NW Y=; X-IronPort-AV: E=Sophos;i="4.67,248,1309737600"; d="scan'208";a="43956150" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 22 Jul 2011 17:59:33 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p6MHxXUt025110; Fri, 22 Jul 2011 17:59:33 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 22 Jul 2011 19:59:33 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 22 Jul 2011 19:59:30 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D05228480@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ADs] AUTH48 [MF]: RFC 6282 Thread-Index: AcxImRixqkScIdlSSUy7pmFNkff3Ow== From: "Pascal Thubert (pthubert)" To: "Zach Shelby" , "Shoichi Sakane" , "RFC Editor" X-OriginalArrivalTime: 22 Jul 2011 17:59:33.0751 (UTC) FILETIME=[1CD04870:01CC4899] X-Mailman-Approved-At: Fri, 22 Jul 2011 11:26:07 -0700 Cc: "Ralph Droms \(rdroms\)" , 6lowpan-chairs@tools.ietf.org, Carsten Bormann , 6lowpan <6lowpan@ietf.org>, 6lowpan-ads@tools.ietf.org Subject: [6lowpan] [ADs] AUTH48 [MF]: RFC 6282 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 17:59:36 -0000 It seems that "IEEE 802.15.4-based Networks" made the consensus. I'll be communicating this to the rfc editor. Thank you all; Pascal > -----Original Message----- > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On > Behalf Of Zach Shelby > Sent: Monday, July 18, 2011 8:39 AM > To: Shoichi Sakane > Cc: 6lowpan > Subject: Re: [6lowpan] Titles of 6LoWPAN RFCs >=20 >=20 > On Jul 14, 2011, at 4:54 PM, Shoichi Sakane wrote: >=20 > >> "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. >=20 >=20 > +1 >=20 > -- > 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 From cabo@tzi.org Fri Jul 22 11:22:42 2011 Return-Path: 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 D843821F8A91 for <6lowpan@ietfa.amsl.com>; Fri, 22 Jul 2011 11:22:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 PAFUhcqogCep for <6lowpan@ietfa.amsl.com>; Fri, 22 Jul 2011 11:22:42 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 1178621F8A58 for <6lowpan@ietf.org>; Fri, 22 Jul 2011 11:22:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id p6MIMQNI001604; Fri, 22 Jul 2011 20:22:26 +0200 (CEST) Received: from [192.168.217.103] (p5B3E6A6D.dip.t-dialin.net [91.62.106.109]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 4DA9C1CE; Fri, 22 Jul 2011 20:22:26 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D05228480@XMB-AMS-107.cisco.com> Date: Fri, 22 Jul 2011 20:22:25 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6A2A459175DABE4BB11DE2026AA50A5D05228480@XMB-AMS-107.cisco.com> To: "Pascal Thubert (pthubert)" X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Fri, 22 Jul 2011 11:26:07 -0700 Cc: "Ralph Droms \(rdroms\)" , RFC Editor , 6lowpan-chairs@tools.ietf.org, Shoichi Sakane , 6lowpan <6lowpan@ietf.org>, 6lowpan-ads@tools.ietf.org Subject: Re: [6lowpan] [ADs] AUTH48 [MF]: RFC 6282 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 18:22:43 -0000 On Jul 22, 2011, at 19:59, Pascal Thubert (pthubert) wrote: > It seems that "IEEE 802.15.4-based Networks" made the consensus. Sorry, Pascal, not so fast. It is a bit hard to diagnose a consensus here, except that the clear WG consensus seems to be that nobody cares much :-) It is indeed pretty clear from the extended WG discussion that Compression Format for IPv6 Datagrams over IEEE 802.15.4-based = Networks or Compression Format for IPv6 Datagrams over IEEE 802.15.4-based = Networks is the important part of the title. We don't seem to have full consensus on whether 6LoWPAN should be part = of the title. Jonathan would like to keep it out, others have indicated that they = think it should be part of the title (as it was during WGLC and IETF = last call). Megan has indicated that 6LoWPAN would be expanded as in RFC 4919: IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): I think the best of both worlds would be Compression Format for IPv6 Datagrams over IEEE 802.15.4-based = Networks (6LoWPANs) but I'd need input from the RFC editor whether that can be done without = falling into the expansion trap. Gruesse, Carsten From cabo@tzi.org Fri Jul 22 11:24:38 2011 Return-Path: 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 DDD8F21F8A91 for <6lowpan@ietfa.amsl.com>; Fri, 22 Jul 2011 11:24:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 BMsMmAvdRKup for <6lowpan@ietfa.amsl.com>; Fri, 22 Jul 2011 11:24:38 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 06AC821F88A0 for <6lowpan@ietf.org>; Fri, 22 Jul 2011 11:24:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id p6MIOQks002289; Fri, 22 Jul 2011 20:24:26 +0200 (CEST) Received: from [192.168.217.103] (p5B3E6A6D.dip.t-dialin.net [91.62.106.109]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 230611CF; Fri, 22 Jul 2011 20:24:26 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: Date: Fri, 22 Jul 2011 20:24:25 +0200 Content-Transfer-Encoding: 7bit Message-Id: <0BAE6C0B-9C5D-4931-B20E-07952DA74DB0@tzi.org> References: <6A2A459175DABE4BB11DE2026AA50A5D05228480@XMB-AMS-107.cisco.com> To: Carsten Bormann X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Fri, 22 Jul 2011 11:26:07 -0700 Cc: "Ralph Droms \(rdroms\)" , RFC Editor , 6lowpan-chairs@tools.ietf.org, Shoichi Sakane , 6lowpan <6lowpan@ietf.org>, 6lowpan-ads@tools.ietf.org Subject: Re: [6lowpan] [ADs] AUTH48 [MF]: RFC 6282 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 18:24:39 -0000 On Jul 22, 2011, at 20:22, Carsten Bormann wrote: > Sorry, Pascal, not so fast. Carsten, not so fast either :-) > Compression Format for IPv6 Datagrams over IEEE 802.15.4-based Networks > > or > > Compression Format for IPv6 Datagrams over IEEE 802.15.4-based Networks Sorry. Compression Format for IPv6 Datagrams over IEEE 802.15.4 Networks or Compression Format for IPv6 Datagrams over IEEE 802.15.4-based Networks is what I wanted to say. Gruesse, Carsten From jari.arkko@piuha.net Sat Jul 23 03:26:22 2011 Return-Path: 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 6277721F85C0; Sat, 23 Jul 2011 03:26:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.419 X-Spam-Level: X-Spam-Status: No, score=-102.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 HrVSn5F-vFIB; Sat, 23 Jul 2011 03:26:21 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id B598521F84FE; Sat, 23 Jul 2011 03:26:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id AB5142CEFF; Sat, 23 Jul 2011 13:26:15 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JL0FqmC9ocxr; Sat, 23 Jul 2011 13:26:14 +0300 (EEST) Received: from [IPv6:::1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id A89E62CC4B; Sat, 23 Jul 2011 13:26:13 +0300 (EEST) Message-ID: <4E2AA1C3.80309@piuha.net> Date: Sat, 23 Jul 2011 06:26:11 -0400 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: core , lwip@ietf.org, roll@ietf.org, 6lowpan@ietf.org References: <4E204877.8040108@piuha.net> In-Reply-To: <4E204877.8040108@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [6lowpan] Internet of Things Hacking Meet 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jul 2011 10:26:22 -0000 Today Saturday we will be at room 301 A from 5PM to 8PM. Note that there will be another meeting finishing at 5PM in the same room. Tomorrow Sunday we will be at 304 B from 7PM to 9PM. This is the IESG meeting room. Jari From salo@saloits.com Sat Jul 23 12:10:50 2011 Return-Path: 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 4067921F8ABB for <6lowpan@ietfa.amsl.com>; Sat, 23 Jul 2011 12:10:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.307 X-Spam-Level: X-Spam-Status: No, score=-1.307 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MISSING_HEADERS=1.292] 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 k4goB0cPuG8n for <6lowpan@ietfa.amsl.com>; Sat, 23 Jul 2011 12:10:49 -0700 (PDT) Received: from server.saloits.com (saloits.com [208.42.140.127]) by ietfa.amsl.com (Postfix) with ESMTP id 5B05921F8A66 for <6lowpan@ietf.org>; Sat, 23 Jul 2011 12:10:25 -0700 (PDT) Received: from [192.168.255.119] (thinkpad2.saloits.com [192.168.255.119]) by server.saloits.com (8.14.4/8.14.3) with ESMTP id p6NJAMC2004959; Sat, 23 Jul 2011 14:10:23 -0500 Message-ID: <4E2B1CA2.2080505@saloits.com> Date: Sat, 23 Jul 2011 14:10:26 -0500 From: "Timothy J. Salo" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 References: <6A2A459175DABE4BB11DE2026AA50A5D05228480@XMB-AMS-107.cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 6lowpan <6lowpan@ietf.org>, 6lowpan-chairs@tools.ietf.org, 6lowpan-ads@tools.ietf.org Subject: Re: [6lowpan] [ADs] AUTH48 [MF]: RFC 6282 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jul 2011 19:10:50 -0000 > It is a bit hard to diagnose a consensus here, except that > the clear WG consensus seems to be that nobody cares much :-) > > It is indeed pretty clear from the extended WG discussion that > > Compression Format for IPv6 Datagrams over IEEE 802.15.4-based Networks > > or > > Compression Format for IPv6 Datagrams over IEEE 802.15.4-based Networks > > is the important part of the title. I think that the name should speak to a large audience (not just the working group or even just the IETF) and should make sense for many years. The "-based" part of the name seems something between subtle and extraneous. If you want to emphasize that this RFC doesn't require or use a full implementation of IEEE 802.15.4, this should be highlighted in the text, not in the title. > We don't seem to have full consensus on whether 6LoWPAN should be part of the title. > Jonathan would like to keep it out, others have indicated that they think it should > be part of the title (as it was during WGLC and IETF last call). "6lowpan", I believe, fails the test of speaking to a broader audience and having longevity. Today, few people know what 6lowpan means, and in the future it will be merely an interesting (or not-so-interesting) historical footnote. Using "6lowpan" feels sort of like using a development code name for a marketing name. > Megan has indicated that 6LoWPAN would be expanded as in RFC 4919: > > IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): I think that the term "personal area networks" is, well, archaic. That is not how IEEE 802.15.4 is being used and not how these specifications are being used. Rather, I think we all hope that this technology will be used for much more than personal area networks. Carsten made essentially this argument in his original e-mail. This reasoning suggests that "6lowpan" doesn't add any value to the title, since it embeds an acronym that we don't really believe. RFC 4944, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", contains neither "based", "6lowpan", nor "personal area networks" in its title. > I think the best of both worlds would be > > Compression Format for IPv6 Datagrams over IEEE 802.15.4-based Networks (6LoWPANs) > > but I'd need input from the RFC editor whether that can be done without > falling into the expansion trap. Again, I think that "6lowpan" is, or soon will be, historical trivia. It's a title that, while we as a working group might have some affection for, we don't really believe it. -tjs From pthubert@cisco.com Sun Jul 24 03:11:00 2011 Return-Path: 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 3543B21F8B24 for <6lowpan@ietfa.amsl.com>; Sun, 24 Jul 2011 03:11:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.099 X-Spam-Level: X-Spam-Status: No, score=-11.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 RdRhsZKfGunY for <6lowpan@ietfa.amsl.com>; Sun, 24 Jul 2011 03:10:59 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 2F46F21F855A for <6lowpan@ietf.org>; Sun, 24 Jul 2011 03:10:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=3495; q=dns/txt; s=iport; t=1311502259; x=1312711859; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=JEwCchNGoZnVcLTMacwyn9yVqjIQLpLZLXyIOAtw50Q=; b=Iw7ZCP2VJW23Sgao60M8fy3IqGeA2afcvum47Rs6ukOsqSrzKP43bmSG kTc/NUI2sgPTHzIikFdCNLrsE1LVFy9MgKkU5uw6J8uA44XQfwZaQpclh GLTwTqsKIJReq7+apkPOqyUcp6GoPDRH3S35URC/A0bqQNuH+xm88427j A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuIAAFPvK06Q/khM/2dsb2JhbAA1AQEBAQMBAQERASEKOgEKDAUCAQkRBAEBCwYjAQYBExgjDggBAQUXDBuXWo9Sd4kAnlOdKIVgXwSYAItS X-IronPort-AV: E=Sophos;i="4.67,255,1309737600"; d="scan'208";a="104030818" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 24 Jul 2011 10:10:57 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p6OAAvMV008925; Sun, 24 Jul 2011 10:10:57 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 24 Jul 2011 12:10:57 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 24 Jul 2011 12:10:54 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D05228523@XMB-AMS-107.cisco.com> In-Reply-To: <4E2B1CA2.2080505@saloits.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] [ADs] AUTH48 [MF]: RFC 6282 Thread-Index: AcxJbEA1gvlGVq4uRa27cSIO5n+ivQAfVpsQ References: <6A2A459175DABE4BB11DE2026AA50A5D05228480@XMB-AMS-107.cisco.com> <4E2B1CA2.2080505@saloits.com> From: "Pascal Thubert (pthubert)" To: "Timothy J. Salo" X-OriginalArrivalTime: 24 Jul 2011 10:10:57.0484 (UTC) FILETIME=[FB09E8C0:01CC49E9] Cc: 6lowpan <6lowpan@ietf.org>, 6lowpan-chairs@tools.ietf.org, 6lowpan-ads@tools.ietf.org Subject: Re: [6lowpan] [ADs] AUTH48 [MF]: RFC 6282 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2011 10:11:00 -0000 Timothy: '-based' was added because 802.15.4 MAC is now used on multiple media including PLC, and HC applies fine to those. In order to include those, we proposed to add frame, or based. Seems that the latter made consensus. Cheers, Pascal > -----Original Message----- > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On > Behalf Of Timothy J. Salo > Sent: Saturday, July 23, 2011 9:10 PM > Cc: 6lowpan; 6lowpan-chairs@tools.ietf.org; 6lowpan-ads@tools.ietf.org > Subject: Re: [6lowpan] [ADs] AUTH48 [MF]: RFC 6282 15.txt> >=20 > > It is a bit hard to diagnose a consensus here, except that > > the clear WG consensus seems to be that nobody cares much :-) > > > > It is indeed pretty clear from the extended WG discussion that > > > > Compression Format for IPv6 Datagrams over IEEE 802.15.4-based > Networks > > > > or > > > > Compression Format for IPv6 Datagrams over IEEE 802.15.4-based > Networks > > > > is the important part of the title. >=20 > I think that the name should speak to a large audience (not just the > working group or even just the IETF) and should make sense for many > years. >=20 > The "-based" part of the name seems something between subtle and > extraneous. If you want to emphasize that this RFC doesn't require > or use a full implementation of IEEE 802.15.4, this should be > highlighted in the text, not in the title. >=20 > > We don't seem to have full consensus on whether 6LoWPAN should be > part of the title. > > Jonathan would like to keep it out, others have indicated that they think it > should > > be part of the title (as it was during WGLC and IETF last call). >=20 > "6lowpan", I believe, fails the test of speaking to a broader audience > and having longevity. Today, few people know what 6lowpan means, and > in the future it will be merely an interesting (or not-so-interesting) > historical footnote. Using "6lowpan" feels sort of like using a > development code name for a marketing name. >=20 > > Megan has indicated that 6LoWPAN would be expanded as in RFC 4919: > > > > IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): >=20 > I think that the term "personal area networks" is, well, archaic. > That is not how IEEE 802.15.4 is being used and not how these > specifications are being used. Rather, I think we all hope that > this technology will be used for much more than personal area > networks. >=20 > Carsten made essentially this argument in his original e-mail. >=20 > This reasoning suggests that "6lowpan" doesn't add any value to the > title, since it embeds an acronym that we don't really believe. >=20 > RFC 4944, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", > contains neither "based", "6lowpan", nor "personal area networks" in > its title. >=20 > > I think the best of both worlds would be > > > > Compression Format for IPv6 Datagrams over IEEE 802.15.4-based > Networks (6LoWPANs) > > > > but I'd need input from the RFC editor whether that can be done without > > falling into the expansion trap. >=20 > Again, I think that "6lowpan" is, or soon will be, historical trivia. > It's a title that, while we as a working group might have some affection > for, we don't really believe it. >=20 > -tjs > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan From jari.arkko@piuha.net Sun Jul 24 13:48:32 2011 Return-Path: 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 54FA921F8562; Sun, 24 Jul 2011 13:48:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.434 X-Spam-Level: X-Spam-Status: No, score=-102.434 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 z6tKEhxO1ovx; Sun, 24 Jul 2011 13:48:31 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id B0DEF21F8506; Sun, 24 Jul 2011 13:48:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 9A1122CE66; Sun, 24 Jul 2011 23:48:29 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ttnf3Y2Ymku9; Sun, 24 Jul 2011 23:48:28 +0300 (EEST) Received: from [IPv6:::1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 9BE4D2CC4B; Sun, 24 Jul 2011 23:48:27 +0300 (EEST) Message-ID: <4E2C851A.9000909@piuha.net> Date: Sun, 24 Jul 2011 16:48:26 -0400 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: core , lwip@ietf.org, roll@ietf.org, 6lowpan@ietf.org References: <4E204877.8040108@piuha.net> <4E2AA1C3.80309@piuha.net> In-Reply-To: <4E2AA1C3.80309@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [6lowpan] [Roll] Internet of Things Hacking Meet 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2011 20:48:32 -0000 An update: We are also today at the same room as yesterday: 301A. Welcome! Jari Jari Arkko kirjoitti: > Today Saturday we will be at room 301 A from 5PM to 8PM. Note that > there will be another meeting finishing at 5PM in the same room. > Tomorrow Sunday we will be at 304 B from 7PM to 9PM. This is the IESG > meeting room. > > Jari > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From rgm@labs.htt-consult.com Mon Jul 25 09:04:38 2011 Return-Path: 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 A46DE21F903C for <6lowpan@ietfa.amsl.com>; Mon, 25 Jul 2011 09:04:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 LaxRakpfG9nd for <6lowpan@ietfa.amsl.com>; Mon, 25 Jul 2011 09:04:37 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by ietfa.amsl.com (Postfix) with ESMTP id 9F9CD21F8BBF for <6lowpan@ietf.org>; Mon, 25 Jul 2011 07:07:13 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 29D4662A94 for <6lowpan@ietf.org>; Mon, 25 Jul 2011 14:07:12 +0000 (UTC) X-Virus-Scanned: amavisd-new at localhost Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iNGpsgCewfog for <6lowpan@ietf.org>; Mon, 25 Jul 2011 10:07:01 -0400 (EDT) Received: from nc2400.htt-consult.com (unknown [207.164.135.98]) (Authenticated sender: rgm@labs.htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPA id B316262A6F for <6lowpan@ietf.org>; Mon, 25 Jul 2011 10:07:01 -0400 (EDT) Message-ID: <4E2D7884.3000003@labs.htt-consult.com> Date: Mon, 25 Jul 2011 10:07:00 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110621 Fedora/3.1.11-1.fc14 Thunderbird/3.1.11 MIME-Version: 1.0 To: 6lowpan@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [6lowpan] An update on IEEE 802.15.4 Key Management 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 16:04:38 -0000 This past week, the Key Management Protocol Interest Group met and moved forward with a plan to develop a transport mechanism for any Key Management Protocol. See presentation: https://mentor.ieee.org/802.15/documents/15-11-0381-03-0hip-KMP-over-4e-Multipurpose.ppt This approach will use the new Information Elements of 802.15.4e and Multipurpose Frames to transport any Key Management Protocol. Now I much prefer that you all use HIP, but I am a realist that more than one screwdriver is needed in the toolbox, so IKEv2, 802.1X, SAE, and a 4-way-handshake (like in 802.11i) will be described. One challenge will be short address selection and collision avoidance. A general method of collision avoidance is needed, as a WPAN could have more than one KMP in use. It is conceivable that this is too hard to resolve, and KMP will be restricted to long addresses. This will be a Recommended Practice. In Okinawa we will be formalizing the design of the transport shim, the Security Association requirements, and how to interact with the 802.15.4 security mechinism as discribed in the forth-coming 802.15.4-2011 (802.15.4i). The draft PAR is: https://mentor.ieee.org/802.15/documents/15-11-0512-01-0hip-Key-Management-Protocol-PAR.doc To participate in this work, please join the HIPIG 802.15 mailing list. Considering our timeline to a PAR (could happen in November), the management does not want to create a KMPIG mailing list. The current documents are under HIPIG, but all documents moving forward will be under KMPIG. I will be available during the week to discuss this. From rgm@labs.htt-consult.com Tue Jul 26 05:06:01 2011 Return-Path: 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 A935521F8BFE for <6lowpan@ietfa.amsl.com>; Tue, 26 Jul 2011 05:06:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 ibMw49JqKBKG for <6lowpan@ietfa.amsl.com>; Tue, 26 Jul 2011 05:06:01 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by ietfa.amsl.com (Postfix) with ESMTP id 2322C21F8BB7 for <6lowpan@ietf.org>; Tue, 26 Jul 2011 05:06:00 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 4E85462A8F for <6lowpan@ietf.org>; Tue, 26 Jul 2011 12:05:57 +0000 (UTC) X-Virus-Scanned: amavisd-new at localhost Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Hy-6S4kb5VU for <6lowpan@ietf.org>; Tue, 26 Jul 2011 08:05:47 -0400 (EDT) Received: from nc2400.htt-consult.com (unknown [130.129.84.202]) (Authenticated sender: rgm@labs.htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPA id 0299362A70 for <6lowpan@ietf.org>; Tue, 26 Jul 2011 08:05:46 -0400 (EDT) Message-ID: <4E2EAD90.4000900@labs.htt-consult.com> Date: Tue, 26 Jul 2011 08:05:36 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110621 Fedora/3.1.11-1.fc14 Thunderbird/3.1.11 MIME-Version: 1.0 To: 6lowpan@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [6lowpan] Ke Management pre 15.4e 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 12:06:01 -0000 I was asked if Key Management can be provided pre-15.4e. A number of concerns were raised about 4e including there are lots of chips out there that do not support it. This is really challenging. I do not see how to suborn an existing Command Frame to carry a KMP. I would have to define a new one and that would be itself a deviation from the existing 802.15 spec. I do not see how to define a Data Payload Field for KMP that would be effective across a number of higher layers. There is no EthType field or similar differentiator. I suspect that within 6lowpan a new Dispatch Type could be defined to carry the KMP. I leave such specific 6lowpan modifications to those that created it. As I define the KMP shim over the next two months, I would be happy to work with some 6lowpan people in developing an ID for its support within 6lowpan as well. Or just fake out the little bit of 4e that I will use for supporting KMP within 4e. The basic thought is to use the new Information Element in either the Multifunction or Command frame. And the Command frame mode only applies to PANs that use the Associate command. So 'just' add what little you need...