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

From: Brian Haberman <[email-masked]>
Date: Mon, 26 Aug 2013 08:19:30 -0400

All,
      I would be interested in feedback on Adrian's concern about the 
reference to an I-D in the charter.

      You can ignore his comment about "IPv6-over-foo", we have already 
straightened that out with him.

Regards,
Brian

-------- Original Message --------
Subject: Adrian Farrel's Block on charter-ietf-6lo-00-00: (with BLOCK 
and COMMENT)
Date: Sun, 25 Aug 2013 11:54:56 -0700
From: Adrian Farrel <[email-masked]>
To: The IESG <[email-masked]>

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/

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

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 26 Aug 2013 15:01:13 +0200

During the BOF, one comment was that we should clarify what a constrained node network is.

The simplest way to accommodate that request seemed to be to add a pointer to the document that explains this term.
At the time it wasn't obvious that there still was a need for discussion for that document.

The new text from Aug 5 was:

# Only specifications targeting constrained nodes and constrained networks, 
# according to the definition in draft-ietf-lwig-terminology, are in scope.

I don't think we actually need the clarification "according..."; it is pretty clear what a constrained node network is.

If people do think we need a clarification, we don't need the pointer to a work-in-progress I-D; we can just copy/paste the two paragraphs.

Grüße, Carsten

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 26 Aug 2013 15:02:15 +0200

Hi,

why not simply copy the _definitions_ (not the explanations) of
Constrained Node, Constrained Network and Constrained Node Network
out of the I-D into the charter?

/js

PS: The main purpose of the MIB modules is to define the instrumentation
    required for monitoring and in particular troubleshooting purposes.

On Mon, Aug 26, 2013 at 08:19:30AM -0400, Brian Haberman wrote:
>      You can ignore his comment about "IPv6-over-foo", we have
> already straightened that out with him.
> 
> Regards,
> Brian
> 
> 
> Subject: Adrian Farrel's Block on charter-ietf-6lo-00-00: (with
> BLOCK and COMMENT)
> _______________________________________________
> 6lo mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lo

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Ulrich Herberg <[email-masked]>
Date: Mon, 26 Aug 2013 09:41:42 -0700

Jürgen,

I think that would work.

Best regards
Ulrich

---

From: Ulrich Herberg <[email-masked]>
Date: Mon, 26 Aug 2013 09:45:19 -0700

Regarding Adrian's comment about "Common infrastructure specifications",
would it help to add more qualification like "Common internet layer and
management infrastructure specifications"?

Best regards
Ulrich

On Mon, Aug 26, 2013 at 5:19 AM, Brian Haberman <[email-masked]>wrote:

> Subject: Adrian Farrel's Block on charter-ietf-6lo-00-00: (with BLOCK and
> COMMENT)
> http://datatracker.ietf.org/**doc/charter-ietf-6lo/<http://datatracker.ietf.org/doc/charter-ietf-6lo/>
>
>
>
> ------------------------------**------------------------------**----------
> BLOCK:
> ------------------------------**------------------------------**----------
>
> ------------------------------**------------------------------**----------
> COMMENT:
> ------------------------------**------------------------------**----------
>
> ______________________________**_________________
> 6lo mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/6lo<https://www.ietf.org/mailman/listinfo/6lo>
>

---

From: Brian Haberman <[email-masked]>
Date: Mon, 26 Aug 2013 13:14:45 -0400

> management infrastructure specifications"?

That sounds almost as non-deterministic as the text Adrian is 
complaining about.  I suggest taking his suggestion to heart and list 
the types of infrastructure you currently have in mind.  The charter can 
be updated to include other types of services if/when they are identified.

Regards,
Brian

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 26 Aug 2013 19:51:28 +0200

On Aug 26, 2013, at 19:14, Brian Haberman <[email-masked]> wrote:

> types of infrastructure 

I think the point was that the WG would like to work on some common components that might be used as part of multiple IP-over-foo specifications for constrained node networks, such as header compression.
Calling that "common infrastructure" is indeed a bit unspecific.

Grüße, Carsten

---

From: Ulrich Herberg <[email-masked]>
Date: Mon, 26 Aug 2013 19:14:52 -0700

Carsten,

maybe we should limit this item to (initially) only header compression?

Best regards
Ulrich

On Mon, Aug 26, 2013 at 10:51 AM, Carsten Bormann <[email-masked]> wrote:

> I think the point was that the WG would like to work on some common
> components that might be used as part of multiple IP-over-foo
> specifications for constrained node networks, such as header compression.

---

From: Robert Cragie <[email-masked]>
Date: Tue, 27 Aug 2013 14:24:51 +0100

+1

Robert

On 26/08/2013 17:41, Ulrich Herberg wrote:
> Jürgen,
>
> I think that would work.
>
> Best regards
> Ulrich
>
>
> On Mon, Aug 26, 2013 at 6:02 AM, Juergen Schoenwaelder 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi,
>
>     > From: Adrian Farrel <[email-masked]
>     <mailto:[email-masked]>>
>     > To: The IESG <[email-masked] <mailto:[email-masked]>>
>     >
>     > [email-masked] <mailto:[email-masked]>
>     Phone: +49 421 200 3587 <tel:%2B49%20421%20200%203587> Campus Ring
>     1, 28759 Bremen, Germany
>     Fax: +49 421 200 3103 <tel:%2B49%20421%20200%203103>
>     <http://www.jacobs-university.de/>
>     [email-masked] <mailto:[email-masked]>

---

From: Robert Cragie <[email-masked]>
Date: Tue, 27 Aug 2013 14:44:12 +0100

I would suggest something like the following change:

"Common infrastructure specifications, such as header compression, 
specific to constrained node networks"

to:

"Specifications, such as header compression, that are applicable to more 
than one adaptation specification"

based on:

1) Changing "IPv6-over-foo specifications" to "adaptation 
specifications"; Brian said IPv6-over-foo had been dealt with but didn't 
say how.
2) No need to mention constrained node networks as "adaptation 
specification" already implies this.

Robert

On 27/08/2013 03:14, Ulrich Herberg wrote:
> On Mon, Aug 26, 2013 at 10:51 AM, Carsten Bormann <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     On Aug 26, 2013, at 19:14, Brian Haberman
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>     > types of infrastructure
>
>     I think the point was that the WG would like to work on some
>     common components that might be used as part of multiple
>     IP-over-foo specifications for constrained node networks, such as
>     header compression.

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 27 Aug 2013 16:09:26 +0200

On Aug 27, 2013, at 15:44, Robert Cragie <[email-masked]> wrote:

> "Specifications, such as header compression, that are applicable to more than one adaptation specification"

Yep (except that I like to call them "adaptation layer specifications"*).

Grüße, Carsten

*) Actually, I called them "IP over Specific Link Layers" some time ago, which led to the ISSLL working group...

---

From: Robert Cragie <[email-masked]>
Date: Tue, 27 Aug 2013 15:18:23 +0100

Hi Carsten,

I like both the terms you mention so either would work for me. I have no 
problem at all with "adaptation layer"; I was simply reluctant to use 
the word "layer" as that tends to have connotations wrt. OSI etc. I have 
often described 6lowpan as "layer 2.5", which clarifies where it sits 
more or less but that's about it.

Robert

---

From: Ralph Droms <[email-masked]>
Date: Tue, 27 Aug 2013 15:44:54 -0700

On Aug 27, 2013, at 7:18 AM 8/27/13, Robert Cragie <[email-masked]> wrote:

> Hi Carsten,
> 
> I like both the terms you mention so either would work for me. I have no problem at all with "adaptation layer"; I was simply reluctant to use the word "layer" as that tends to have connotations wrt. OSI etc. I have often described 6lowpan as "layer 2.5", which clarifies where it sits more or less but that's about it.

Good discussion.  Thanks.  Will one of you send text with concrete proposals to changes to the charter?  OLD:/NEW: format is probably best for these revisions.

- Ralph

---

From: Ulrich Herberg <[email-masked]>
Date: Tue, 27 Aug 2013 19:31:21 -0700

How about:

=============
OLD:
6Lo focuses on INT area work that is needed for constrained node networks,
as defined in section 2.1. and 2.2. of draft-ietf-lwig-terminology.

NEW:
6Lo focuses on INT area work that is needed for constrained node networks,
using the following definitions:
  -  Constrained Node:  A node where some of the characteristics that are
otherwise pretty much taken for granted for Internet nodes in 2013 are not
attainable, often due to cost constraints and/or physical constraints on
characteristics such as size, weight, and available power and energy.
  -  Constrained Network:  A network where some of the characteristics
pretty much taken for granted with link layers in common use in the
Internet by 2013, are not attainable.
=============

Specifically, it is working on
  - IPv6-over-foo specifications using 6LoWPAN technologies (RFC4944,
RFC6282, RFC6775) for link layer technologies of interest in constrained
node networks;

=============
OLD
  - related MIBs;

NEW
  - related MIB modules;
=============

=============
OLD
  - common infrastructure specification such as header compression specific
to constrained node networks;

NEW
  - specifications, such as header compression, that are applicable to more
than one adaptation layer specification;
=============

  -  maintenance and informational documents required for the existing IETF
specifications in this space.

=============
OLD
Only specifications targeting constrained nodes and constrained networks,
according to the definition in draft-ietf-lwig-terminology, are in scope.

NEW
Only specifications targeting constrained nodes and constrained networks,
according to the above definitions of these terms, 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 INT area work. 6Lo does not take on
larger cross-layer efforts (such as the 6TSCH work under discussion). 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 today ROLL (RTG) and CoRE (APP), and
appropriate groups in the IETF OPS and Security areas including potential
future groups spawned from efforts such as COMAN and SOLACE.

On Tue, Aug 27, 2013 at 3:44 PM, Ralph Droms <[email-masked]> wrote:

> problem at all with "adaptation layer"; I was simply reluctant to use the
> word "layer" as that tends to have connotations wrt. OSI etc. I have often
> described 6lowpan as "layer 2.5", which clarifies where it sits more or
> less but that's about it.
>
> Good discussion.  Thanks.  Will one of you send text with concrete
> proposals to changes to the charter?  OLD:/NEW: format is probably best for
> these revisions.
>
> - Ralph
>
> >
> > Robert
> >
> >> *) Actually, I called them "IP over Specific Link Layers" some time
> ago, which led to the ISSLL working group...
> >>

---

From: Robert Cragie <[email-masked]>
Date: Wed, 28 Aug 2013 08:52:41 +0100

Looks good. I would suggest one more minor change:

=============
OLD

NEW
   - IPv6-over-foo adaptation layer specifications using 6LoWPAN 
technologies (RFC4944, RFC6282, RFC6775) for link layer technologies of 
interest in constrained node networks;
=============

Robert

On 28/08/2013 03:31, Ulrich Herberg wrote:
> How about:
>
> =============
> OLD:
> 6Lo focuses on INT area work that is needed for constrained node 
> networks, as defined in section 2.1. and 2.2. of 
> draft-ietf-lwig-terminology.
>
> NEW:
> 6Lo focuses on INT area work that is needed for constrained node 
> networks, using the following definitions:
>   -  Constrained Node:  A node where some of the characteristics that 
> are otherwise pretty much taken for granted for Internet nodes in 2013 
> are not attainable, often due to cost constraints and/or physical 
> constraints on characteristics such as size, weight, and available 
> power and energy.
> RFC6282, RFC6775) for link layer technologies of interest in 
> constrained node networks;
>
> =============
> OLD
>   - related MIBs;
>
> NEW
>   - related MIB modules;
> =============
>
>
> =============
> OLD
>   - common infrastructure specification such as header compression 
> specific to constrained node networks;
>
> NEW
>   - specifications, such as header compression, that are applicable to 
> more than one adaptation layer specification;
> =============
>
>   -  maintenance and informational documents required for the existing 
> IETF specifications in this space.
>
>
> =============
> OLD
> Only specifications targeting constrained nodes and constrained 
> networks, according to the definition in draft-ietf-lwig-terminology, 
> are in scope.
>
> NEW
> Only specifications targeting constrained nodes and constrained 
> networks, according to the above definitions of these terms, 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 INT area work. 6Lo does not take 
> on larger cross-layer efforts (such as the 6TSCH work under 
> discussion). 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 today ROLL 
> (RTG) and CoRE (APP), and appropriate groups in the IETF OPS and 
> Security areas including potential future groups spawned from efforts 
> such as COMAN and SOLACE.
>
>
> On Tue, Aug 27, 2013 at 3:44 PM, Ralph Droms <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
>     On Aug 27, 2013, at 7:18 AM 8/27/13, Robert Cragie
>     <[email-masked] <mailto:[email-masked]>>
>     wrote:
>
>     > Hi Carsten,
>     >
>     > I like both the terms you mention so either would work for me. I
>     have no problem at all with "adaptation layer"; I was simply
>     reluctant to use the word "layer" as that tends to have
>     connotations wrt. OSI etc. I have often described 6lowpan as
>     "layer 2.5", which clarifies where it sits more or less but that's
>     about it.
>
>     proposals to changes to the charter?  OLD:/NEW: format is probably
>     best for these revisions.
>
>     - Ralph
>
>     >
>     > Robert
>     >
>     >> On Aug 27, 2013, at 15:44, Robert Cragie
>     <[email-masked] <mailto:[email-masked]>>
>     wrote:
>     >>
>     >>> "Specifications, such as header compression, that are
>     applicable to more than one adaptation specification"
>     >> *) Actually, I called them "IP over Specific Link Layers" some
>     time ago, which led to the ISSLL working group...
>     >>

---

From: "Timothy J. Salo" <[email-masked]>
Date: Wed, 28 Aug 2013 03:37:42 -0500

How about:
> constraints on characteristics such as size, weight, and available power
> and energy.

NEWEST:
6lo focuses on INT-area work that is needed for constrained networks,
those in which certain resources are severely limited, such as
bandwidth, computational power, storage, power, or energy.

- - - - - - - - - - - - -

Note: I don't think that we really care about, for example, size and
weight constraints, except to the extent that these limitations affect
the amount of things we care about (e.g., bandwidth, computational
power, storage, ...).  That is, I suggest that we talk about only the
things that affect us.  I further suggest that mention of such things
as cost, size, weight, and other things that affect us only indirectly,
is superfluous.

-tjs

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 28 Aug 2013 10:51:26 +0200

Hi,

please note that a 'constrained network' is not the same as a
'constrained node network' according to [1] and NEWEST is now moving
from 'constrained node networks' to 'constrained networks'.

The original charter text talked about constrained node networks and
if that was by intention, we should use a wording like this:

  6Lo focuses on INT area work that is needed for constrained node
  networks, i.e., networks whose characteristics are influenced by
  being composed of a significant portion of constrained nodes. A
  constrained node is a node where some of the characteristics that
  are otherwise pretty much taken for granted for Internet nodes in
  2013 are not attainable.

[1] draft-ietf-lwig-terminology-05.txt

/js

---

From: Robert Cragie <[email-masked]>
Date: Wed, 28 Aug 2013 10:04:25 +0100

I prefer Ulrich's text based on copying the text verbatim from 
draft-ietf-lwig-terminology-05. Don't forget this was only a BLOCK 
because it was referring to an ID - this has been fixed.

Robert

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 28 Aug 2013 11:07:06 +0200

Hi,

but let me note that the copied text did not explain 'constrained node
network'.

/js

---

From: Robert Cragie <[email-masked]>
Date: Wed, 28 Aug 2013 10:24:08 +0100

A couple more suggested tweaks:

1. For completeness we also include the definition of "Constrained node 
network" from draft-ietf-lwig-terminology-05:

Constrained Node Network:  A network whose characteristics are 
influenced by being composed of a significant portion of constrained nodes.

2. Use the term "constrained node networks" as the target for the WG, 
with the implication this refers to constrained nodes and constrained 
networks as defined.

So here is the suggested complete OLD/NEW charter text, based on 
http://datatracker.ietf.org/doc/charter-ietf-6lo/ as written and 
bracketed by <charter text></charter text>:

<charter text>
=============
OLD:
6Lo focuses on INT area work that is needed for constrained node 
networks, as defined in section 2.1. and 2.2. of 
draft-ietf-lwig-terminology. Specifically, it will work on:

1. IPv6-over-foo specifications using 6LoWPAN technologies (RFC4944, 
RFC6282, RFC6775) for link layer technologies of interest in constrained 
node networks

2. Related MIBs

3. Common infrastructure specifications, such as header compression, 
specific to constrained node networks

NEW:

   -  Constrained Node:  A node where some of the characteristics that 
are otherwise pretty much taken for granted for Internet nodes in 2013 
are not attainable, often due to cost constraints and/or physical 
constraints on characteristics such as size, weight, and available power 
and energy.
   -  Constrained Network:  A network where some of the characteristics 
pretty much taken for granted with link layers in common use in the 
Internet by 2013, are not attainable.
   -  Constrained Node Network:  A network whose characteristics are 
influenced by being composed of a significant portion of constrained nodes.

Specifically, it will work on:

1. IPv6-over-foo adaptation layer specifications using 6LoWPAN 
technologies (RFC4944, RFC6282, RFC6775) for link layer technologies of 
interest in constrained node networks

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:

NEW:
Only specifications targeting constrained nodes networks, according to 
the above definitions of these terms, 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 INT area work. 6Lo does not take 
on larger cross-layer efforts (such as the 6TSCH work under discussion). 
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 today ROLL (RTG) 
and CoRE (APP), and appropriate groups in the IETF OPS and Security 
areas including potential future groups spawned from efforts such as 
COMAN and SOLACE.
</charter text>

Robert

---

From: Robert Cragie <[email-masked]>
Date: Wed, 28 Aug 2013 10:27:52 +0100

Argh, one tiny blip spotted (I wrote "constrained nodes networks"). Try 
again:

<charter text>
=============
OLD:

2. Related MIBs

NEW:

2. Related MIB modules

=============
OLD:

NEW:
Only specifications targeting constrained node networks, according to 
the above definitions of these terms, are in scope.
=============

On 28/08/2013 10:24, Robert Cragie wrote:
> 1. For completeness we also include the definition of "Constrained 
> node network" from draft-ietf-lwig-terminology-05:
>
> constrained node networks
>
> 2. Related MIBs
>
> technologies (RFC4944, RFC6282, RFC6775) for link layer technologies 
> of interest in constrained node networks
>
> 2. Related MIB modules
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 28 Aug 2013 11:51:30 +0200

On Wed, Aug 28, 2013 at 10:24:08AM +0100, Robert Cragie wrote:
 
> 2. Use the term "constrained node networks" as the target for the
> WG, with the implication this refers to constrained nodes and
> constrained networks as defined.

If the idea is to cover constrained networks as well as constrained
node networks, I would prefer to have this stated explicitely.

/js

---

From: Ralph Droms <[email-masked]>
Date: Wed, 28 Aug 2013 08:40:50 -0700

Would late binding on the definitions lack sufficient specificity (the following is based mostly on Robert's suggested modifications)?

<charter text>
=============
OLD:
6Lo focuses on INT area work that is needed for constrained node networks, as defined in section 2.1. and 2.2. of draft-ietf-lwig-terminology. Specifically, it will work on:

1. IPv6-over-foo specifications using 6LoWPAN technologies (RFC4944, RFC6282, RFC6775) for link layer technologies of interest in constrained node networks

2. Related MIBs

3. Common infrastructure specifications, such as header compression, specific to constrained node networks

NEW:
6Lo focuses on INT area work that is needed for constrained node networks, as that term is defined by the LWIG working group.

1. IPv6-over-foo adaptation layer specifications using 6LoWPAN technologies (RFC4944, RFC6282, RFC6775) for link layer technologies of interest in constrained node networks

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 nodes and constrained networks, according to the definition in draft-ietf-lwig-terminology, are in scope.

NEW:
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 INT area work. 6Lo does not take on larger cross-layer efforts (such as the 6TSCH work under discussion). 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 today ROLL (RTG) and CoRE (APP), and appropriate groups in the IETF OPS and Security areas including potential future groups spawned from efforts such as COMAN and SOLACE.
</charter text>

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 28 Aug 2013 17:53:42 +0200

On Aug 28, 2013, at 17:40, Ralph Droms <[email-masked]> wrote:

> late binding

I like that text a lot.

Purists won't like that it seems to give LWIG power to redefine the charter of 6LO.

(I'm German, but not that much of a purist :-)

Grüße, Carsten

---

From: Ulrich Herberg <[email-masked]>
Date: Wed, 28 Aug 2013 09:02:33 -0700

+1

---

From: Ralph Droms <[email-masked]>
Date: Wed, 28 Aug 2013 09:08:19 -0700

> On Aug 28, 2013, at 17:40, Ralph Droms <[email-masked]> wrote:

Great!

> Purists won't like that it seems to give LWIG power to redefine the charter of 6LO.

6lo can always recharter if lwig takes its definitions off in a different direction.

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Wed, 28 Aug 2013 09:30:05 -0700

Updated to incorporate Sean Turner's suggested changes.

<charter text>
=============
OLD:

2. Related MIBs

NEW:

2. Related MIB modules

=============
OLD:

NEW:

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).
</charter text>

---

From: Ulrich Herberg <[email-masked]>
Date: Wed, 28 Aug 2013 10:45:29 -0700

It seems like the modification proposed by Sean is not surrounded by
OLD/NEW (in the last sentence). Shouldn't it be:

<charter text>
=============
OLD:

2. Related MIBs

NEW:
6Lo focuses on INT area work that is needed for constrained node networks,
as that term is defined by the LWIG working group.

1. IPv6-over-foo adaptation layer specifications using 6LoWPAN technologies
(RFC4944, RFC6282, RFC6775) for link layer technologies of interest in
constrained node networks

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:

NEW:

=============
OLD:

NEW:
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).
=============
</charter text>

On Wed, Aug 28, 2013 at 9:30 AM, Ralph Droms <[email-masked]> wrote:

> as that term is defined by the LWIG working group.
>
> on constrained node networks, such as ROLL (RTG) and CoRE (APP).
> </charter text>
>

---

From: Ralph Droms <[email-masked]>
Date: Wed, 28 Aug 2013 11:27:05 -0700

You're right.  Thanks for the correction.

- Ralph

On Aug 28, 2013, at 10:45 AM 8/28/13, Ulrich Herberg <[email-masked]> wrote:

> It seems like the modification proposed by Sean is not surrounded by OLD/NEW (in the last sentence). Shouldn't it be:
> 
> <charter text>
> =============
> OLD:

---

From: Brian Haberman <[email-masked]>
Date: Wed, 28 Aug 2013 14:37:36 -0400

I will get these changes incorporated into the datatracker version of 
the charter and point Adrian & Sean at it.

Regards,
Brian

---

From: Ralph Droms <[email-masked]>
Date: Wed, 28 Aug 2013 11:39:35 -0700

Thanks.

- Ralph

On Aug 28, 2013, at 11:37 AM 8/28/13, Brian Haberman <[email-masked]> wrote:

> I will get these changes incorporated into the datatracker version of the charter and point Adrian & Sean at it.
> 
> Regards,
> Brian
>

---

From: Brian Haberman <[email-masked]>
Date: Wed, 28 Aug 2013 14:50:28 -0400

All,
      this is what I am going to submit to the datatracker.  Can someone 
confirm that it captures all the proposed changes before I hit 'Submit'?

Brian

--

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

2. Related MIB modules

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

Only specifications targeting constrained nodes 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).

---

From: Ulrich Herberg <[email-masked]>
Date: Wed, 28 Aug 2013 11:56:07 -0700

Thanks, Brian. I noticed one difference. The text I sent out in NEW said:

        Only specifications targeting constrained node networks are in
scope.

Your text says:

         Only specifications targeting constrained nodes are in scope.

(without "networks"). Is this intentional? Or maybe I have just missed a
previous conclusion on this sentence.

Ulrich

On Wed, Aug 28, 2013 at 11:50 AM, Brian Haberman
<[email-masked]>wrote:

> 4. Maintenance and informational documents required for the existing IETF
> 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.
>

---

From: Brian Haberman <[email-masked]>
Date: Wed, 28 Aug 2013 14:57:49 -0400

Cut/Paste error on my part (now fixed).

Brian

---

From: Ulrich Herberg <[email-masked]>
Date: Wed, 28 Aug 2013 12:00:05 -0700

Thanks

Ulrich

On Wed, Aug 28, 2013 at 11:57 AM, Brian Haberman
<[email-masked]>wrote:

>> <[email-masked]>**wrote:
>>
>>  All,
>>> being
>>> ______________________________****_________________
>>> 6lo mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/****listinfo/6lo<https://www.ietf.org/mailman/**listinfo/6lo>
>>> <https://www.**ietf.org/mailman/listinfo/6lo<https://www.ietf.org/mailman/listinfo/6lo>
>>> >
>>>
>>>
>>
>

---

From: Ralph Droms <[email-masked]>
Date: Wed, 28 Aug 2013 12:00:23 -0700

> Cut/Paste error on my part (now fixed).

Looks OK to me (with cut/paste error fixed).

- Ralph

---

From: Brian Haberman <[email-masked]>
Date: Wed, 28 Aug 2013 15:42:41 -0400

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 6LoWPAN 
RFCs  are applicable.

Regards,
Brian

>
> A
>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian
>> Haberman
>> Sent: 28 August 2013 20:04
>> To: [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:

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 28 Aug 2013 20:56:53 +0100

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

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

Adrian

> Sent: 28 August 2013 20:43
> To: [email-masked]
> Cc: [email-masked]

---

From: Brian Haberman <[email-masked]>
Date: Wed, 28 Aug 2013 16:17:29 -0400

Adrian,

> using technologies previously described by the 6LoWPAN working group.

The above is fine with me.  I will wait to see if there are objections 
from the mailing list.

> (RFC4944, RFC6282, RFC6775).

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.

Regards,
Brian

---

From: Ralph Droms <[email-masked]>
Date: Wed, 28 Aug 2013 14:47:36 -0700

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

> 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

---

From: Ulrich Herberg <[email-masked]>
Date: Thu, 29 Aug 2013 08:58:04 -0700

(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]>wrote:

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

---

From: Robert Cragie <[email-masked]>
Date: Thu, 29 Aug 2013 17:02:06 +0100

+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
>
>
>     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).
>
>
>     The line is quite clear to me and it is drawn based on where the
>             From: [email-masked] <mailto:[email-masked]>
>             [mailto:[email-masked]
>             <mailto:[email-masked]>] On Behalf Of Brian
>             Haberman
>             To: [email-masked] <mailto:[email-masked]>

---

From: Ulrich Herberg <[email-masked]>
Date: Thu, 29 Aug 2013 09:02:28 -0700

I agree with Ralph and Brian (on both points).

Ulrich

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

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

---

From: Brian Haberman <[email-masked]>
Date: Thu, 29 Aug 2013 12:06:13 -0400

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

---

From: Ulrich Herberg <[email-masked]>
Date: Thu, 29 Aug 2013 09:15:28 -0700

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
>
>
>>> <[email-masked] <mailto:brian@innovationslab.**net<[email-masked]>>>
>>> wrote:
>>>
>>>     Hi Adrian,
>>>             <mailto:[email-masked]>**] On Behalf Of Brian
>>>             Haberman

---

From: Brian Haberman <[email-masked]>
Date: Thu, 29 Aug 2013 12:21:24 -0400

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

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 29 Aug 2013 18:25:54 +0200

On Aug 29, 2013, at 18:21, Brian Haberman <[email-masked]> wrote:

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

The narrow definition of 6LoWPAN is that of "IP-over-foo for IEEE 802.15.4".  We can't use that.

The wider explanation in the LWIG draft:

   One interesting class of a constrained network often used as a
   constrained node network is the "LoWPAN" [RFC4919], a term inspired
   from the name of the IEEE 802.15.4 working group (low-rate wireless
   personal area networks (LR-WPANs)).  [...]
   Originally focused on IEEE 802.15.4, "LoWPAN" (or when used for IPv6,
   "6LoWPAN") is now also being used for networks built from similarly
   constrained link layer technologies [I-D.ietf-6lowpan-btle]
   [I-D.mariager-6lowpan-v6over-dect-ule] [I-D.brandt-6man-lowpanz].

So it refers back to "constrained", but without using the other definitions in the LWIG terminology.

Grüße, Carsten

---

From: Samita Chakrabarti <[email-masked]>
Date: Sat, 31 Aug 2013 01:14:33 +0000

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:

6Lo focuses on Internet Area work that is needed for constrained node 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. 

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

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.

CURRENT:
Security and management work that is not specific to the link layers being
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.

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)

Thoughts?  Proposed text?

Brian

On 8/29/13 12:15 PM, Ulrich Herberg wrote:
>>>> <[email-masked] 
>>>> <mailto:brian@innovationslab.**net<[email-masked]>>>
>>>> wrote:
>>>>
>>>>      Hi Adrian,

---

From: Robert Cragie <[email-masked]>
Date: Sat, 31 Aug 2013 10:34:43 +0100

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

> 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>
> 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>
> If so,  it would be good to clarify them.
<RCC>Given the statement regarding security and management, I would 
think not</RCC>
> 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>