Subject: [6lo] Dave Thaler's comments on charter

From: Brian Haberman <[email-masked]>
Date: Sat, 07 Sep 2013 09:48:11 -0400

Something to consider while updating to address Adrian's comments.

Brian

-------- Original Message --------
Subject: RE: [IAB] Internal WG Review: IPv6 over Networks of 
Resource-constrained Nodes	(6lo)
Date: Fri, 6 Sep 2013 20:51:27 +0000
From: Dave Thaler <[email-masked]>
To: [email-masked] <[email-masked]>, [email-masked] <[email-masked]>

I have one concern about the proposed charter.

To repeat what I said in my BOF evaluation, attached:
> Another aspect of the scope discussion was the relationship between this BOF
> and what is in scope of 6man (other IP-over-Foo mechanisms), where the proposed
> 6lo charter makes âconstrained node networksâ in scope for 6lo and leaves the rest
> for 6man.   My own take is that I agree with the goal to keep architectural impact out
> of 6lo (but in 6man instead) and as such, 6lo should be scoped to things where the
> architecture doesnât change from existing RFCs (whether 6lowpanâs architectural
> model or the Ethernet architectural model).  This is narrower than the definition
> of âconstrained node networkâ.  If the scope is really âconstrained node networkâ
> then I donât think they can (or should) avoid a discussion of architectural model
> whenever someone comes in with a doc on a âconstrained node networkâ that
> canât completely emulate Ethernet or 6lowpanâs model.

The proposed charter below keeps all "constrained node networks" in 
scope and
does explain that

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

However, I don't think it's specific enough about what are "implications 
on IPv6
architecture".  I think it should explicitly say something like:

> For adaptation layer
> specifications that do not have implications on IPv6 architecture
> (and expose to IPv6 the same type of link as used by either Ethernet or 6lowpan),

Or equivalent.   Otherwise, someone will subtly change the link model 
and claim
it has no implications on IPv6 architecture because it doesn't use IPv6 
addresses
in any specific way or use any new ND options.

-Dave

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of IESG
> Secretary
> Sent: Monday, August 26, 2013 10:38 AM
> To: [email-masked]; [email-masked]
> Subject: [IAB] Internal WG Review: IPv6 over Networks of Resource-
> constrained Nodes (6lo)
>
> A new IETF working group is being considered in the Internet Area.  The draft
> charter for this working group is provided below for your review
> and comment.
>
> Review time is one week.
>
> The IETF Secretariat
>
> IPv6 over Networks of Resource-constrained Nodes (6lo)
> --------------------------------------------------
> Current Status: Proposed Working Group
>
> Personnel
>   Chairs: TBD
>   Area Director: Brian Haberman <[email-masked]>
>   Tech Advisor: Ralph Droms <[email-masked]>
>
> Mailing List
>   Address: [email-masked]
>   To Subscribe: https://www.ietf.org/mailman/listinfo/6lo
>   Archive: http://www.ietf.org/mail-archive/web/6lo/current/maillist.html
>
> 6Lo focuses on Internet 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
>
> 4. Maintenance and informational documents required for the existing IETF
> specifications in this space.
>
> Only specifications targeting constrained nodes and constrained networks,
> according to the definition in draft-ietf-lwig-terminology, 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 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.
>
> Proposed Milestones
>
> No milestones for charter found.

Subject: [IAB] IETF87 6lo BOF evaluation
From: Dave Thaler <[email-masked]>
To: IAB <[email-masked]>, The IESG <[email-masked]>
Date: Fri, 2 Aug 2013 07:53:29 +0000
List-Id: "Internet Architecture Board \(IAB\)" <iab.iab.org>

I attended the 6lo BOF that discussed IPv6 over networks of resource-constrained nodes. This was a WG-forming BOF, and it was explained that this BOF is sort of a successor to the half-closed (draining output queue, no input) 6lowpan WG which I understood was scoped to a particular link technology (802.15.4).  The 6lo BOF on the other hand discussed applicability of the same protocol solutions to other similar link types (G.9959, RS485, etc.).  There seemed to be general agreement that the 6lowpan mechanisms include a number of modules, and those modules could be individually reused.  There was a question about whether an architectural description would be in scope, and there seemed to be general agreement to not do so in the proposed WG, but rather only refer to what 6lowpan already did.  That seems like a good idea to me as long as all the link types that 6lo would do are very similar to 802.15.4. That is, I think it might be good to scope a 6lo WG as such.

One of the scope discussions in the BOF was about the use of the term "constrained node network" throughout the proposed charter and what that was (e.g., I asked if a carrier pigeon network was one :)   The LWIG WG has a terminology doc<http://tools.ietf.org/html/draft-ietf-lwig-terminology> that defines it, and it was agreed to incorporate the definition into the proposed charter.   Another aspect of the scope discussion was the relationship between this BOF and what is in scope of 6man (other IP-over-Foo mechanisms), where the proposed 6lo charter makes "constrained node networks" in scope for 6lo and leaves the rest for 6man.   My own take is that I agree with the goal to keep architectural impact out of 6lo (but in 6man instead) and as such, 6lo should be scoped to things where the architecture doesn't change from existing RFCs (whether 6lowpan's architectural model or the Ethernet architectural model).  This is narrower than the definition of "constrained node network".  If the scope is really "constrained node network" then I don't think they can (or should) avoid a discussion of architectural model whenever someone comes in with a doc on a "constrained node network" that can't completely emulate Ethernet or 6lowpan's model.

At the end of the BOF, the chairs poll the room on a number of questions:

1)      Should the IETF address a problem here?  There was strong support for yes.

2)      Do folks agree with the proposed charter (with some mods as discussed during the meeting)?  Again strong support for yes.

3)      Are there people willing to do work?   There were 30-ish hands for willing to comment on docs.  There were 10-ish hands for willing to edit docs.  There were 25-ish hands for willing to implement docs.

So it seemed to me that this is about ready to form a WG, and the next step for the IESG is to decide an appropriate scope.

-Dave

---

From: Brian Haberman <[email-masked]>
Date: Tue, 24 Sep 2013 09:39:41 -0400

Dave indicated that he has not seen any resolution to the issues he raised.

Brian

On 9/7/13 9:48 AM, Brian Haberman wrote:
> _______________________________________________
> 6lo mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lo
>

---

From: Ulrich Herberg <[email-masked]>
Date: Wed, 25 Sep 2013 15:10:02 -0700

Dave,

sorry for the late reply. I agree with your comment. Would the
following change address your concern?

======================
OLD
For adaptation layer specifications that do not have implications on
IPv6 architecture,
6man will be notified about 6lo's working group last call.

NEW
For adaptation layer specifications that do not have implications on
IPv6 architecture
and expose IPv6 to the same type of link as used by either Ethernet or 6lowpan,
6man will be notified about 6lo's working group last call.
======================

Best regards
Ulrich

On Tue, Sep 24, 2013 at 6:39 AM, Brian Haberman
<[email-masked]> wrote:
>>> 6lo charter makes â€œconstrained node networksâ€  in scope for 6lo and
>>> leaves the rest
>>> architecture doesnâ€™t change from existing RFCs (whether 6lowpanâ€™s
>>> architectural
>>> of â€œconstrained node networkâ€ .  If the scope is really
>>> â€œconstrained node networkâ€
>>> then I donâ€™t think they can (or should) avoid a discussion of
>>> architectural model
>>> whenever someone comes in with a doc on a â€œconstrained node
>>> networkâ€  that
>>> canâ€™t completely emulate Ethernet or 6lowpanâ€™s model.
>>