Subject: Re: [6lo] Adrian Farrel's Block on charter-ietf-6lo-00-00: (with BLOCK and COMMENT)

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 1 Sep 2013 18:53:47 +0100

All, 
 
I really want to get out of the way of this work.
 
I understand that the proposed wording:
- does not preclude the necessary work being done in 6man
- does not stop any of the intended work being done in 6lo
 
Both of these are good objectives.
 
My concern is that the wording does not prevent other work being done in 6lo
that has not been dreamed of and would be out of scope if we could dream of it.
I am probably *way* too paranoid, but I am trying to find a form that scopes in
the work you want to do *and* scopes out the work you have no intention of
doing.
 
Happy to hear any other suggestions.
Thanks,
Adrian
 
From: Ulrich Herberg [mailto:[email-masked]] 
Sent: 29 August 2013 17:02
To: Ralph Droms
Cc: Haberman Brian; Farrel Adrian; [email-masked] IESG; [email-masked]
Subject: Re: [6lo] Adrian Farrel's Block on charter-ietf-6lo-00-00: (with BLOCK
and COMMENT)
 
I agree with Ralph and Brian (on both points).

Ulrich
 
On Wed, Aug 28, 2013 at 2:47 PM, Ralph Droms <[email-masked]> wrote:

On Aug 28, 2013, at 1:17 PM 8/28/13, Brian Haberman <[email-masked]>
wrote:

> Adrian,
>
> On 8/28/13 3:56 PM, Adrian Farrel wrote:
>> Hi again,
>>
>> You say that the distinction between 6lo and 6man is drawn based on where the
>> 6LoWPAN RFCs are applicable.
>> Is it necessary to say, in the charter, where those RFCs are applicable?
>>
>> Currently there is an attempt via "for link layer technologies of interest in
>> constrained node networks." But maybe you would only use the 6LoWPAN RFCs in
>> environments where they are applicable, in which case we can resolve by
changing
>> to say...
>>
>> OLD
>> 6Lo focuses on Internet Area work that is needed for constrained node
>> networks, as the term is defined by the LWIG working group.
>> NEW
>> 6Lo focuses on Internet Area work that is needed for IPv6 adaptation
>> using technologies previously described by the 6LoWPAN working group.
>> END
>>
>
> The above is fine with me.  I will wait to see if there are objections from
the mailing list.
Looking at the list of candidate documents from Carsten's BoF presentation, this
revised text looks OK.  It fits around those candidate documents, as long as
"technologies previously described by the 6LoWPAN working group" is interpreted
liberally enough to allow modifications to the technologies as required by the
specific adaptation.

>
>> and
>>
>> OLD
>> 1. IPv6-over-foo adaptation layer specifications using 6LoWPAN technologies
>> (RFC4944, RFC6282, RFC6775) for link layer technologies of interest in
>> constrained node networks
>> NEW
>> 1. IPv6-over-foo adaptation layer specifications using 6LoWPAN technologies
>> (RFC4944, RFC6282, RFC6775).
>> END
>
> So, *I* think this change is a little problematic.  As a data point, there are
components of the 6LoWPAN work that are being proposed for inclusion in the base
IPv6 specifications (e.g., draft-chakrabarti-nordmark-6man-efficient-nd).  That
draft takes changes made to NDP for these "constrained node networks" and
applies them to all link layers, including Ethernet.  Dropping that descriptor
from the charter would essentially allow 6lo to work on any link layer
technology.
Again reviewing Carsten's presentation, the original text would not conflict
with the list of documents proposed for consideration in 6lo, and I agree with
Brian that work like draft-chakrabarti-nordmark-6man-efficient-nd, which applies
to all link layers, should stay in 6man.

> Regards,
> Brian

- Ralph

>
>
> _______________________________________________
> 6lo mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lo

_______________________________________________
6lo mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/6lo

---

From: Ulrich Herberg <[email-masked]>
Date: Tue, 3 Sep 2013 09:33:57 -0700

Adrian,

as a first step towards resolving your "Block", would you agree if we copy
the current definitions of Constrained Node, Constrained Network and
Constrained Node Network from the LWIG draft into the charter, instead of
citing the draft or referring to the LWIG work in general?

Best regards
Ulrich

On Sun, Sep 1, 2013 at 10:53 AM, Adrian Farrel <[email-masked]> wrote:

> All, ****
>
> ** **
>
> I really want to get out of the way of this work.****
>
> ** **
>
> I understand that the proposed wording:****
>
> - does not preclude the necessary work being done in 6man****
>
> - does not stop any of the intended work being done in 6lo****
>
> ** **
>
> Both of these are good objectives.****
>
> ** **
>
> My concern is that the wording does not prevent other work being done in
> 6lo that has not been dreamed of and would be out of scope if we could
> dream of it.****
>
> I am probably *way* too paranoid, but I am trying to find a form that
> scopes in the work you want to do *and* scopes out the work you have no
> intention of doing.****
>
> ** **
>
> Happy to hear any other suggestions.****
>
> Thanks,****
>
> Adrian****
>
> ** **
>
> *From:* Ulrich Herberg [mailto:[email-masked]]
> *Sent:* 29 August 2013 17:02
> *To:* Ralph Droms
> *Cc:* Haberman Brian; Farrel Adrian; [email-masked] IESG; [email-masked]
> *Subject:* Re: [6lo] Adrian Farrel's Block on charter-ietf-6lo-00-00:
> (with BLOCK and COMMENT)****
>
> ** **
>
> Ulrich****
> ** **
> On Wed, Aug 28, 2013 at 2:47 PM, Ralph Droms <[email-masked]>
> wrote:****
>
>
> On Aug 28, 2013, at 1:17 PM 8/28/13, Brian Haberman <
> [email-masked]> wrote:
>
> > Adrian,
> >
> > The above is fine with me.  I will wait to see if there are objections
> from the mailing list.****
>
> Looking at the list of candidate documents from Carsten's BoF
> presentation, this revised text looks OK.  It fits around those candidate
> documents, as long as "technologies previously described by the 6LoWPAN
> working group" is interpreted liberally enough to allow modifications to
> the technologies as required by the specific adaptation.****
>
>
> >
> >> and
> >>
> >> OLD
> > So, *I* think this change is a little problematic.  As a data point,
> there are components of the 6LoWPAN work that are being proposed for
> inclusion in the base IPv6 specifications (e.g.,
> draft-chakrabarti-nordmark-6man-efficient-nd).  That draft takes changes
> made to NDP for these "constrained node networks" and applies them to all
> link layers, including Ethernet.  Dropping that descriptor from the charter
> would essentially allow 6lo to work on any link layer technology.****
>
> Again reviewing Carsten's presentation, the original text would not
> conflict with the list of documents proposed for consideration in 6lo, and
> I agree with Brian that work like
> draft-chakrabarti-nordmark-6man-efficient-nd, which applies to all link
> layers, should stay in 6man.
>
> >
> > Regards,
> > Brian
>
> - Ralph****
>
>
> >
> >
> https://www.ietf.org/mailman/listinfo/6lo****
>
> ** **
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 7 Sep 2013 20:06:24 +0100

Hi Ulrich,
 
Sorry for the delay while travelling.
 
I *do* believe that explicitly stating the definition of Constrained Things in
the charter text will be a very positive step.
 
But please understand that, per my Discuss on the LWIG terminology I-D, I find
the definition of a constrained node in that document rather poor.
 
I am beginning to sense "I can't describe a constrained node, but I know one
when I see one."
 
My suggestion for resolving that part of my Discuss is to remove the formal
definition from the text and simply leave a description that will make it clear
what is intended. That might be a better approach in this charter as well.
 
Cheers,
Adrian
 
From: Ulrich Herberg [mailto:[email-masked]] 
Sent: 03 September 2013 17:34
To: [email-masked]
Cc: Ralph Droms; Haberman Brian; The IESG; [email-masked]
Subject: Re: [6lo] Adrian Farrel's Block on charter-ietf-6lo-00-00: (with BLOCK
and COMMENT)
 
Adrian,

as a first step towards resolving your "Block", would you agree if we copy the
current definitions of Constrained Node, Constrained Network and Constrained
Node Network from the LWIG draft into the charter, instead of citing the draft
or referring to the LWIG work in general? 
Best regards
Ulrich

 

 

Ulrich

changing
the mailing list.

- Ralph

---

From: Ulrich Herberg <[email-masked]>
Date: Mon, 9 Sep 2013 08:43:42 -0700

Hi Adrian,

On Sat, Sep 7, 2013 at 12:06 PM, Adrian Farrel <[email-masked]> wrote:

> Hi Ulrich,****
>
> ** **
>
> Sorry for the delay while travelling.****
>
> ** **
>
> I *do* believe that explicitly stating the definition of Constrained
> Things in the charter text will be a very positive step.
>

Good, thanks.

> ****
>
> ** **
>
> But please understand that, per my Discuss on the LWIG terminology I-D, I
> find the definition of a constrained node in that document rather poor.
>

I just read the text of your DISCUSS on that document.

> ****
>
> ** **
>
> I am beginning to sense "I can't describe a constrained node, but I know
> one when I see one."****
>
> ** **
>
> My suggestion for resolving that part of my Discuss is to remove the
> formal definition from the text and simply leave a description that will
> make it clear what is intended. That might be a better approach in this
> charter as well.
>

It surprises me that we already have multiple WG working on constrained
nodes and constrained networks, e.g., ROLL, CORE, LWIG, MANET, but just now
we start setting boundaries for when a node/network is "constrained".
Moreover, there seems to be some vague separation in the IETF between
"constrained" (e.g., MANET) and "more constrained" (e.g., ROLL).
To me, the term LLN has a lot of similarities with "constrained node
network". As the definition of LLN is in the (approved) charter of ROLL, is
the wording in that charter something that we can reuse? (apart from the
focus on routing)

Best regards
Ulrich

** **
> *Sent:* 03 September 2013 17:34
> *To:* [email-masked]
> *Cc:* Ralph Droms; Haberman Brian; The IESG; [email-masked]
>
> citing the draft or referring to the LWIG work in general? ****
>
> Best regards
> Ulrich****
>
> ** **
>
> On Sun, Sep 1, 2013 at 10:53 AM, Adrian Farrel <[email-masked]>
> wrote:****
>
> All, ****
>
>  ****
>
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 9 Sep 2013 18:52:12 +0200

On Sep 9, 2013, at 17:43, Ulrich Herberg <[email-masked]> wrote:

> To me, the term LLN has a lot of similarities with "constrained node network". As the definition of LLN is in the (approved) charter of ROLL, is the wording in that charter something that we can reuse? (apart from the focus on routing)

Let's see:

> Generally speaking,

Hmm.

> LLNs have at least five distinguishing
> characteristics:
> - LLNs operate with a hard, very small bound on state.

This does fit quite well with constrained nodes.

> - In most cases, LLN optimize for saving energy.

In most cases, this fits well, too.
(Most networks are starting to do this a bit as well, though.)

> - Typical traffic patterns are not simply unicast flows (e.g. in some
> cases most if not all traffic can be point to multipoint).

I don't know what is distinguishing here.

> - In most cases, LLNs will be employed over link layers with 
> restricted frame-sizes, thus a routing protocol for LLNs should be
> specifically
> adapted for such link layers.

In many cases, this fits well, too, but it is not exactly a distinguishing characteristic of the 6lo adaptation layers (other adaptation layers do segmentation/fragmentation, and not all 6lo ones will need to).

> - LLN routing protocols have to be very careful when trading off
> efficiency for generality; many LLN nodes do not have resources to 
> waste.

This is one of the main considerations for protocols in a constrained node network, so it does apply to adaptation layer specifications as well.  I'm not sure that it doesn't also apply to, say, 10 gig Ethernet.

The main point about 6lo is that it is connecting specific link layer technologies that have been developed for constrained node networks.  It is not a prerequisite for a node itself to actually be constrained to take part in a 6lo network, but it is an objective that, as well as the link layer technology, the adaptation layer *can* be implemented on a constrained node.

Grüße, Carsten

---

From: Ulrich Herberg <[email-masked]>
Date: Mon, 9 Sep 2013 11:45:33 -0700

Hi Carsten,

thanks for the comments. Below is a proposal for an updated charter.
I wonder if the term constrained node network (CNN) is actually 100%
equivalent to LLN (in which case we may not need to create another term; in
particular one that sounds like a TV channel ;-) Or are there differences
between the two terms?

<charter text>
=============
OLD
6Lo focuses on Internet Area work that is needed for constrained node
networks,
as the term is defined by the LWIG working group.

NEW
6Lo focuses on Internet Area work that is needed for constrained node
networks (CNN).
CNNs consist of many
embedded devices with limited power, memory, and processing
resources. They are interconnected by a variety of links, such as
IEEE 802.15.4, Bluetooth, Low Power WiFi, wired or other low
power Powerline Communication (PLC) links. CNNs are transitioning
to an end-to-end IP-based solution to avoid the problem of
non-interoperable networks interconnected by protocol translation
gateways and proxies.

CNNs have at least the following distinguishing
characteristics:
- CNNs operate with a hard, very small bound on state.
- In most cases, CNNs optimize for saving energy.
- In many cases, CNNs will be employed over link layers with
restricted frame-sizes.
- CNN protocols have to be careful when trading off
efficiency for generality; many nodes in a CNN do not have resources to
waste.
=============

=============
OLD
Specifically, it will work on:

NEW
Specifically, 6lo will work on:
=============

2. Related MIB modules

3. Specifications, such as header compression, that are applicable to more
than one adaptation layer specification

4. Maintenance and informational documents required for the existing IETF
specifications in this space.

=============
OLD
Only specifications targeting constrained node networks are in scope.

NEW
Only specifications that can be implemented for a constrained node in a
CNN, as defined above, are in scope.
=============

6Lo will work closely with the 6man working group, which will continue to
work on IP-over-foo documents outside the constrained node network space
and will continue to be the focal point for IPv6 maintenance. For
adaptation layer specifications that do not have implications on IPv6
architecture, 6man will be notified about 6Lo's working group last call.
Specifications that might have such an impact (e.g., by using IPv6
addresses in a specific way or by introducing new ND options) will be
closely coordinated with 6man, and/or specific parts will be fanned out to
6man documents. Beyond 6man, 6Lo will also coordinate with LWIG and INTAREA.

6Lo works on small, focused pieces of Internet Area work. 6Lo does not take
on larger cross-layer efforts. The working group will continue to reuse
existing protocols and mechanisms whenever reasonable and possible.

Security and management work that is not specific to the link layers being
worked on is out of scope. Work related to routing is out of scope. 6Lo
will coordinate closely with the working groups in other areas that focus
on constrained node networks, such as ROLL (RTG) and CoRE (APP).

On Mon, Sep 9, 2013 at 9:52 AM, Carsten Bormann <[email-masked]> wrote:

> In many cases, this fits well, too, but it is not exactly a distinguishing
> characteristic of the 6lo adaptation layers (other adaptation layers do
> segmentation/fragmentation, and not all 6lo ones will need to).
>
> This is one of the main considerations for protocols in a constrained node
> network, so it does apply to adaptation layer specifications as well.  I'm
> not sure that it doesn't also apply to, say, 10 gig Ethernet.
>
> The main point about 6lo is that it is connecting specific link layer
> technologies that have been developed for constrained node networks.  It is
> not a prerequisite for a node itself to actually be constrained to take
> part in a 6lo network, but it is an objective that, as well as the link
> layer technology, the adaptation layer *can* be implemented on a
> constrained node.
>
> Grüße, Carsten
>
>

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 9 Sep 2013 21:14:47 +0200

On Sep 9, 2013, at 20:45, Ulrich Herberg <[email-masked]> wrote:

> I wonder if the term constrained node network (CNN) is actually 100% equivalent to LLN (in which case we may not need to create another term; in particular one that sounds like a TV channel ;-) Or are there differences between the two terms?

Well, the terms do overlap in usage, but that doesn't mean they are redundant.

The term "low-power lossy networks" focuses on two aspects of constrainedness:

-- low-power (which might be a proxy to constrainedness in energy usage), and
-- lossy (which might express one aspect of the constrainedness of the network).

The way the term is used also seems to include other aspects, such as mostly-static topologies with high fluctuation in packet delivery rate, scaling up high-power radio networks, collection tree flows.
The term does not express the other dimensions of constrainedness of the nodes themselves, which is really the motivating factor for many things we do in the constrained node networks space.
Copying over the old LLN text and using it as a definition of constrained node networks would be a serious regression; we have arrived at a much better understanding already.
Saying that 6lo is about LLNs also is confusing, because I don't think we want to address WiFi, BNEP-style Bluetooth or the Ethernet-like forms of PLC.

(I never use the abbreviation, so I don't care about the TV channel.)

Grüße, Carsten

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 9 Sep 2013 22:11:46 +0100

Hi,
 
I think you have hit on a key point. The LWIG document appears to make an
attempt to redefine the concept of constrained node, and that runs up against
existing definitions.
 
Actually, that may be harsh! LWIG is trying to define the term, and (as you
note) previous usages have been somewhat vague. Unfortunately (IMHO) the attempt
in LWIG to meet the challenge head on has resulted in a rather vague definition.

We could:
a. Work together on the LWIG definition and then re-use it for the 6lo charter
b. Come up with a concise definition for the 6lo charter
 
I think b) would be faster and better. 
 
Looking at the definition in ROLL I find draft-ietf-roll-terminology that says
"An LLN is typically composed of many embedded devices with limited power,
memory, and processing resources interconnected by a variety of links." That
would certainly cover it (there is nothing specific about routing in that
definition), but it might also be nice to replace "a variety of links" with
something a bit more specific. That would cut into my other concern about which
(or what type of) links this work is intended to cover.
 
Cheers,
Adrian
 
From: Ulrich Herberg [mailto:[email-masked]] 
Sent: 09 September 2013 16:44
To: [email-masked]
Cc: Ralph Droms; Haberman Brian; The IESG; [email-masked]
Subject: Re: [6lo] Adrian Farrel's Block on charter-ietf-6lo-00-00: (with BLOCK
and COMMENT)
 
Hi Adrian,

 
 
Good, thanks.

 
 
It surprises me that we already have multiple WG working on constrained nodes
and constrained networks, e.g., ROLL, CORE, LWIG, MANET, but just now we start
setting boundaries for when a node/network is "constrained". Moreover, there
seems to be some vague separation in the IETF between "constrained" (e.g.,
MANET) and "more constrained" (e.g., ROLL).
To me, the term LLN has a lot of similarities with "constrained node network".
As the definition of LLN is in the (approved) charter of ROLL, is the wording in
that charter something that we can reuse? (apart from the focus on routing)

Best regards
Ulrich

 
Adrian,

 

 

 

Ulrich

changing
the mailing list.

- Ralph

---

From: Samita Chakrabarti <[email-masked]>
Date: Tue, 10 Sep 2013 01:44:56 +0000

Hi Robert,

Your point is taken. We also heard from Adrian and his suggestions:

"I *do* believe that explicitly stating the definition of Constrained Things
in the charter text will be a very positive step. 
But please understand that, per my Discuss on the LWIG terminology I-D, I
find the definition of a constrained node in that document rather poor."

So, it looks like we have to do some more work on the definition of
"Constrained" nodes and networks  in order to make a progress.

Thanks,
-Samita

-----Original Message-----
From: Robert Cragie [mailto:[email-masked]] 
Sent: Saturday, August 31, 2013 2:35 AM
To: Samita Chakrabarti
Cc: Brian Haberman; Ulrich Herberg; [email-masked]
Subject: Re: [6lo] Adrian Farrel's Block on charter-ietf-6lo-00-00: (with
BLOCK and COMMENT)

Hi Samita,

Comments inline.

To summarise: I think we are going around in circles re. "constrained" 
terms and I support Ulrich's suggestion to copy the terms from 
draft-ietf-lwig-terminology verbatim.

Robert

On 31/08/2013 02:14, Samita Chakrabarti wrote:
> Hi All,
>
> There have been a lot of discussion in the list and I am catching up with
them.
>
> Here are some proposed text for the charter and some thoughts ( as per the
following email  from Brian ) .
> CURRENT
> NEW:
Networks. The constrained node networks have  limited functionality compared
to the  common IP networks composed of line-powered and high-capacity
devices. An example of constrained networks is IPv6 over IEEE
802.15.4(6LoWPAN).
> The constrained nodes can be characterized by many different categories
such as node capability, cost of networks, media constraints, regulatory
limits, bit-rates etc.
<RCC>I think we are going around in circles here. I support Ulrich's 
suggestion to simply copy the definitions from 
draft-ietf-lwig-terminology. On the basis that it is almost impossible 
to provide a definitive objective statement about what a "constrained" 
anything is, I think the terms in draft-ietf-lwig-terminology are well 
considered and well qualified. Whilst the qualifications are dealt with 
more in the LWIG WG, the charter states that there will be coordination 
with LWIG, so I don't see what else needs to be done for this.</RCC>
>
>
> CURRENT
> 6Lo works on small, focused pieces of Internet Area work. 6Lo does not
take on
> larger cross-layer efforts. The working group will continue to reuse
existing
> protocols and mechanisms whenever reasonable and possible.
>
> QUESTION:  Would like to know what we mean by "small focused pieces of
Internet Area work" ?
>
> Would it be better to say "6Lo will work on focused pieces of Internet
Area for which the work already started
> on the IPv6-over-foo and provide generic guidelines for IPv6 running on
constrained link-layers".
<RCC>The suggested text seems to preclude starting work for other 
as-yet-to-be-determined link layers applicable to constrained node 
networks, which would not be the case, surely? "small, focused pieces of 
Internet Area work" is clear enough to me.</RCC>
>
> Will this group develop any work on provisioning of the constrained nodes?
Gateway devices between Internet (IPv6) and  constrained networks?
> If so,  it would be good to clarify them.
<RCC>Given the statement regarding security and management, I would 
think not</RCC>
> CURRENT:
> worked on is out of scope.
>
> QUESTION: Is it trying to say?
>
> Any new security and management work that is not specific to the
constrained link, is out of scope.
> This sentence is not clear to me.
<RCC>
I would rather not bring in another "constrained" term here. I think the 
sentence as it stands is OK - a possible change which may clarify would 
be something like:

"Security and management work that is not specific to the link layers 
under consideration is out of scope."
</RCC>
>
>
> The rest looks fine to me.
>
> Thanks,
> -Samita
>
>
>
>
>
>
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
Brian Haberman
> Sent: Thursday, August 29, 2013 9:21 AM
> To: Ulrich Herberg
> Cc: [email-masked]; [email-masked]
> Subject: Re: [6lo] Adrian Farrel's Block on charter-ietf-6lo-00-00: (with
BLOCK and COMMENT)
>
> Is it possible to scope the work using a definition of 6LoWPAN rather than
the definitions in the LWIG draft?  Adrian holds a DISCUSS on the LWIG draft
because of the scoping of those definitions.  He proposed that the 6lo
charter avoid those definitions by scoping its work based on some 6LoWPAN
description/definition.
>
> Thoughts?  Proposed text?
>
> Brian
>
> On 8/29/13 12:15 PM, Ulrich Herberg wrote:
>> Thanks!
>>
>>
>> On Thu, Aug 29, 2013 at 9:06 AM, Brian Haberman
<[email-masked]>wrote:
>>
>>> We will be discussing the charter in the next few hours on the IESG
call.
>>>    I will ask if this approach will alleviate their concerns.
>>>
>>> Brian
>>>
>>>
>>> On 8/29/13 12:02 PM, Robert Cragie wrote:
>>>
>>>> +1
>>>>
>>>> I was going to suggest the same.
>>>>
>>>> Robert
>>>>
>>>> On 29/08/2013 16:58, Ulrich Herberg wrote:
>>>>
>>>>> (dropping IESG from cc)
>>>>>
>>>>> As Stewart raises a similar concern, maybe we could go back to my
>>>>> initial proposal to copy the current LWIG definitions inside the
charter?
>>>>>
>>>>> Ulrich
>>>>>
>>>>>
>>>>> On Wed, Aug 28, 2013 at 12:42 PM, Brian Haberman
>>>>> <[email-masked]
>>>>> <mailto:brian@innovationslab.**net<[email-masked]>>>
>>>>> wrote:
>>>>>
>>>>>       Hi Adrian,
>>>>>            I have CC:'ed the 6lo mailing list to keep them in the
loop...
>>>>>
>>>>>       On 8/28/13 3:23 PM, Adrian Farrel wrote:
>>>>>
>>>>>           Thanks for the heads-up, Brian.
>>>>>
>>>>>           I think that replacing the reference to the draft with a
>>>>>           statement that the
>>>>>           definition is produced in another WG might not be good
enough.
>>>>>           How will this WG know what to work on until LWIG have
defined
>>>>>           the concepts?
>>>>>
>>>>>
>>>>>       The key work is extending the 6LoWPAN RFCs to other link layers.
>>>>>        The LWIG definition offers a baseline for where those RFCs may
be
>>>>>       applicable.  One option thrown around on the mailing list was to
>>>>>       add the definitions to the charter rather than rely on the LWIG
>>>>>       document (which is no longer mentioned in the charter).
>>>>>
>>>>>
>>>>>           Maybe, however, the issue is that you are trying to split
6lo
>>>>>           work from 6man
>>>>>           work using a line that is hard to draw. How constrained does
a
>>>>>           node have to be
>>>>>           before the work moves from 6man to 6lo?
>>>>>
>>>>>
>>>>>       The line is quite clear to me and it is drawn based on where the
>>>>>           A
>>>>>               -----Original Message-----
>>>>>               From: [email-masked]
<mailto:[email-masked]>
>>>>>               [mailto:[email-masked]
>>>>>               <mailto:[email-masked]>**] On Behalf Of Brian
>>>>>               Haberman
>>>>>               Sent: 28 August 2013 20:04
>>>>>               To: [email-masked] <mailto:[email-masked]>
>>>>>               Subject: Re: Adrian Farrel's Block on
>>>>>               charter-ietf-6lo-00-00: (with BLOCK and
>>>>>               COMMENT)
>>>>>
>>>>>               Adrian,
>>>>>               The charter text has been updated to address the issues
>>>>>               you raised.
>>>>>               Please review!
>>>>>
>>>>>               Brian
>>>>>
>>>>>
>>>>>               On 8/25/13 2:54 PM, Adrian Farrel wrote:
>>>>>
>>>>>                   Adrian Farrel has entered the following ballot
>>>>>                   position for
>>>>>                   charter-ietf-6lo-00-00: Block
>>>>>
>>>>>                   When responding, please keep the subject line intact
>>>>>                   and reply to all
>>>>>                   email addresses included in the To and CC lines.
(Feel
>>>>>                   free to cut this
>>>>>                   introductory paragraph, however.)
>>>>>
>>>>>
>>>>>
>>>>>                   The document, along with other ballot positions, can
>>>>>                   be found here:
>>>>>                   
>>>>> http://datatracker.ietf.org/**doc/charter-ietf-6lo/<http://datatrac
>>>>> ker.ietf.org/doc/charter-ietf-6lo/>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------**------------------------------**
>>>>> ----------
>>>>>                   BLOCK:
>>>>>
>>>>> ------------------------------**------------------------------**
>>>>> ----------
>>>>>
>>>>>                   My main concern is that it is not appropriate for a
>>>>>                   charter to give, as a
>>>>>                   key
>>>>>                   reference scoping its work, a pointer to an
>>>>>                   Internet-Draft.  This is not
>>>>>                   only
>>>>>                   the case because I-Ds contain boiler-plate saying
that
>>>>>                   it is
>>>>>                   inappropriate to
>>>>>                   cite them, but also because the definitions in the
>>>>>                   referenced I-D are
>>>>>                   currently
>>>>>                   under debate and the subject of an IESG Discuss.
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------**------------------------------**
>>>>> ----------
>>>>>                   COMMENT:
>>>>>
>>>>> ------------------------------**------------------------------**
>>>>> ----------
>>>>>
>>>>>                   My other concerns are considerably addressed by the
>>>>>                   last two paragraphs,
>>>>>                   but
>>>>>                   would, I think benefit from some word-smithing...
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>                   "IPv6-over-foo specifications" is particularly
loose.
>>>>>                    TCP is an
>>>>>                   IP-over-foo
>>>>>                   technology.  Can the proposed working group work on
>>>>>                   it?  What about
>>>>>                   enhancements
>>>>>                   to TCP to take account of the constrained nature of
>>>>>                   the under-lying
>>>>>                   network?
>>>>>
>>>>>                   It is possible that this work is intended to be
scoped
>>>>>                   to foo being one
>>>>>                   of the
>>>>>                   technologies covered by RFC4944, RFC6282, RFC6775,
but
>>>>>                   that is not
>>>>>                   clear.
>>>>>
>>>>>                   ---
>>>>>
>>>>>                       Common infrastructure specifications, such as
>>>>>                   header compression,
>>>>>                       specific to constrained node networks
>>>>>
>>>>>                   Maybe "common infrastructure" has a specific meaning
>>>>>                   in the Internet
>>>>>                   Area, but
>>>>>                   some people might assume that a routing protocol was
a
>>>>>                   common
>>>>>                   infrastructure :-)
>>>>>                   I would, for example, consider mesh-under routing
>>>>>                   protocols to be suspect
>>>>>                   within
>>>>>                   this scope, but would find it hard to scope them out
>>>>>                   witthese words.
>>>>>
>>>>>                   If you have other things in mind, it might be good
to
>>>>>                   list them. If
>>>>>                   header
>>>>>                   compression is the only one, then perhaps change the
>>>>>                   to talk only about
>>>>>                   that.
>>>>>
>>>>>                   Maybe also be careful to narrow down which headers
you
>>>>>                   mean.
>>>>>
>>>>>                   ---
>>>>>
>>>>>                   Nit...
>>>>>
>>>>>                   s/MIBs/MIB modules/
>>>>>
>>>>>                   And maybe you want to say for what purpose. Many
folk
>>>>>                   feel they are
>>>>>                   obliged to write
>>>>>                   MIB modules these days, but don't really know why
they
>>>>>                   are doing it.
>>>>>
>>>>>
>>>>>       ______________________________**_________________
>>>>>       6lo mailing list
>>>>>       [email-masked] <mailto:[email-masked]>
>>>>>
>>>>>       
>>>>> https://www.ietf.org/mailman/**listinfo/6lo<https://www.ietf.org/ma
>>>>> ilman/listinfo/6lo>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ______________________________**_________________
>>>>> 6lo mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/**listinfo/6lo<https://www.ietf.org/ma
>>>>> ilman/listinfo/6lo>
>>>>>
>>>>
>>>>

---

From: Samita Chakrabarti <[email-masked]>
Date: Thu, 12 Sep 2013 00:42:11 +0000

Hi Adrian,

As per your suggestion on a concise definition of constrained networks for the 6lo charter,  we worked on a revised text.
Please let us know if this description/definition addresses your concerns.

Here it is.

Best regards,
-Samita
OLD
===

NEW
===
6Lo focuses on Internet Area work that is needed for constrained node
networks with the characteristics of:
* limited power, memory and processing resources
* hard upper bounds on state, code space and processing cycles
* optimization of energy and network bandwidth usage
* lack of some layer 2 services like complete device connectivity and
  broadcast/multicast

OLD
==
==

Revised Charter text (proposed):

6Lo focuses on Internet Area work that is needed for constrained node
Networks with the characteristics of:
* limited power, memory and processing resources
* hard upper bounds on state, code space and processing cycles
* optimization of energy and network bandwidth usage
* lack of some layer 2 services like complete device connectivity and
  broadcast/multicast

2. Related MIB modules

Only specifications targeting constrained node networks are in scope. 6Lo will
work closely with the 6man working group, which will continue to work on
IP-over-foo documents outside the constrained node network space and will
continue to be the focal point for IPv6 maintenance. For adaptation layer
specifications that do not have implications on IPv6 architecture, 6man will be
notified about 6Lo's working group last call. Specifications that might have
such an impact (e.g., by using IPv6 addresses in a specific way or by
introducing new ND options) will be closely coordinated with 6man, and/or
specific parts will be fanned out to 6man documents. Beyond 6man, 6Lo will also
coordinate with LWIG and INTAREA.

6Lo works on small, focused pieces of Internet Area work. 6Lo does not take on
larger cross-layer efforts. The working group will continue to reuse existing
protocols and mechanisms whenever reasonable and possible.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: Monday, September 09, 2013 2:12 PM
To: 'Ulrich Herberg'
Cc: 'Haberman Brian'; [email-masked]; 'Ralph Droms'; 'The IESG'
Subject: Re: [6lo] Adrian Farrel's Block on charter-ietf-6lo-00-00: (with BLOCK and COMMENT)

Hi,

I think you have hit on a key point. The LWIG document appears to make an attempt to redefine the concept of constrained node, and that runs up against existing definitions.

Actually, that may be harsh! LWIG is trying to define the term, and (as you note) previous usages have been somewhat vague. Unfortunately (IMHO) the attempt in LWIG to meet the challenge head on has resulted in a rather vague definition.

We could:

Looking at the definition in ROLL I find draft-ietf-roll-terminology that says "An LLN is typically composed of many embedded devices with limited power, memory, and processing resources interconnected by a variety of links." That would certainly cover it (there is nothing specific about routing in that definition), but it might also be nice to replace "a variety of links" with something a bit more specific. That would cut into my other concern about which (or what type of) links this work is intended to cover.

Cheers,
Adrian

From: Ulrich Herberg [mailto:[email-masked]]
Sent: 09 September 2013 16:44
To: [email-masked]<mailto:[email-masked]>
Cc: Ralph Droms; Haberman Brian; The IESG; [email-masked]<mailto:[email-masked]>
Subject: Re: [6lo] Adrian Farrel's Block on charter-ietf-6lo-00-00: (with BLOCK and COMMENT)

Hi Adrian,

On Sat, Sep 7, 2013 at 12:06 PM, Adrian Farrel <[email-masked]<mailto:[email-masked]>> wrote:
Hi Ulrich,

I *do* believe that explicitly stating the definition of Constrained Things in the charter text will be a very positive step.

Good, thanks.

But please understand that, per my Discuss on the LWIG terminology I-D, I find the definition of a constrained node in that document rather poor.

I am beginning to sense "I can't describe a constrained node, but I know one when I see one."

My suggestion for resolving that part of my Discuss is to remove the formal definition from the text and simply leave a description that will make it clear what is intended. That might be a better approach in this charter as well.

It surprises me that we already have multiple WG working on constrained nodes and constrained networks, e.g., ROLL, CORE, LWIG, MANET, but just now we start setting boundaries for when a node/network is "constrained". Moreover, there seems to be some vague separation in the IETF between "constrained" (e.g., MANET) and "more constrained" (e.g., ROLL).
To me, the term LLN has a lot of similarities with "constrained node network". As the definition of LLN is in the (approved) charter of ROLL, is the wording in that charter something that we can reuse? (apart from the focus on routing)

Best regards
Ulrich

From: Ulrich Herberg [mailto:[email-masked]<mailto:[email-masked]>]
Sent: 03 September 2013 17:34
To: [email-masked]<mailto:[email-masked]>
Cc: Ralph Droms; Haberman Brian; The IESG; [email-masked]<mailto:[email-masked]>

Subject: Re: [6lo] Adrian Farrel's Block on charter-ietf-6lo-00-00: (with BLOCK and COMMENT)

Adrian,

as a first step towards resolving your "Block", would you agree if we copy the current definitions of Constrained Node, Constrained Network and Constrained Node Network from the LWIG draft into the charter, instead of citing the draft or referring to the LWIG work in general?
Best regards
Ulrich

On Sun, Sep 1, 2013 at 10:53 AM, Adrian Farrel <[email-masked]<mailto:[email-masked]>> wrote:
All,

My concern is that the wording does not prevent other work being done in 6lo that has not been dreamed of and would be out of scope if we could dream of it.
I am probably *way* too paranoid, but I am trying to find a form that scopes in the work you want to do *and* scopes out the work you have no intention of doing.

From: Ulrich Herberg [mailto:[email-masked]<mailto:[email-masked]>]
Sent: 29 August 2013 17:02
To: Ralph Droms
Cc: Haberman Brian; Farrel Adrian; [email-masked]<mailto:[email-masked]> IESG; [email-masked]<mailto:[email-masked]>
Subject: Re: [6lo] Adrian Farrel's Block on charter-ietf-6lo-00-00: (with BLOCK and COMMENT)

Ulrich

On Wed, Aug 28, 2013 at 2:47 PM, Ralph Droms <[email-masked]<mailto:[email-masked]>> wrote:

On Aug 28, 2013, at 1:17 PM 8/28/13, Brian Haberman <[email-masked]<mailto:[email-masked]>> wrote:

>> environments where they are applicable, in which case we can resolve by changing
>> to say...
>>
>> OLD
> The above is fine with me.  I will wait to see if there are objections from the mailing list.
Looking at the list of candidate documents from Carsten's BoF presentation, this revised text looks OK.  It fits around those candidate documents, as long as "technologies previously described by the 6LoWPAN working group" is interpreted liberally enough to allow modifications to the technologies as required by the specific adaptation.

> So, *I* think this change is a little problematic.  As a data point, there are components of the 6LoWPAN work that are being proposed for inclusion in the base IPv6 specifications (e.g., draft-chakrabarti-nordmark-6man-efficient-nd).  That draft takes changes made to NDP for these "constrained node networks" and applies them to all link layers, including Ethernet.  Dropping that descriptor from the charter would essentially allow 6lo to work on any link layer technology.
Again reviewing Carsten's presentation, the original text would not conflict with the list of documents proposed for consideration in 6lo, and I agree with Brian that work like draft-chakrabarti-nordmark-6man-efficient-nd, which applies to all link layers, should stay in 6man.

- Ralph

> [email-masked]<mailto:[email-masked]>

_______________________________________________
6lo mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/6lo

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 13 Sep 2013 13:31:49 +0100

Thanks,
 
This would work for me.
 
Adrian
 
From: Samita Chakrabarti [mailto:[email-masked]] 
Sent: 12 September 2013 01:42
To: [email-masked]; 'Ulrich Herberg'
Cc: 'Haberman Brian'; [email-masked]; 'Ralph Droms'; [email-masked]
Subject: RE: [6lo] Adrian Farrel's Block on charter-ietf-6lo-00-00: (with BLOCK
and COMMENT)
 
Hi Adrian,
 
As per your suggestion on a concise definition of constrained networks for the
6lo charter,  we worked on a revised text. 
Please let us know if this description/definition addresses your concerns. 
 
Here it is.
 
Best regards,
-Samita
OLD
===
 
NEW
===
 
OLD
==

 
 
2. Related MIB modules

 

 

From: [email-masked] [mailto:[email-masked]] On Behalf Of Adrian
Farrel
Sent: Monday, September 09, 2013 2:12 PM
To: 'Ulrich Herberg'
Cc: 'Haberman Brian'; [email-masked]; 'Ralph Droms'; 'The IESG'
Subject: Re: [6lo] Adrian Farrel's Block on charter-ietf-6lo-00-00: (with BLOCK
and COMMENT)
 
Hi,

We could:

 
Cheers,
Adrian

Hi Adrian,

 
 
Good, thanks.

 

Best regards
Ulrich

 
Adrian,

 

 

 

Ulrich

changing
the mailing list.

- Ralph