IPv6 over networks of resource-constrained nodes
charter-ietf-6lo-02

As this is mainly a refresh of the charter (adding new published RFC and new related WGs + removing concluding WGs), suggest to skip the external review (the 6LO WG has reviewed this update at IETF-121 + mailing list).

[Ballot comment]
The discussion went in the right direction. I trust Brian will take of my BLOCK. Cleared now.

Via email, Carsten proposed: "I think the decision that the current one will be a MIB module should be in the milestones, and the charter should say how we arrive at these decisions."

The proposed milestones addition would be a plus.

[Ballot comment]
Via email, Carsten proposed: "I think the decision that the current one will be a MIB module should be in the milestones, and the charter should say how we arrive at these decisions."

The proposed milestones addition would be a plus.

[Ballot block]
I have no general concern about chartering this WG but I would like to see a
clarification with respect to this point:

"6lo focuses on Internet Area work that is needed for constrained node
networks with the characteristics of:"

What does Internet Area work mean?
Btw, you want a MIB module, should we add OPS in there?
Proposal: remove "Internet Area"

Same remark for "6lo works on small, focused pieces of Internet Area work."
It clashes with

    2. Information and data models (e.g., MIB modules) for these
    adaptation layers for basic monitoring and troubleshooting.

[Ballot comment]
Via email, Carsten proposed: "I think the decision that the current one will be a MIB module should be in the milestones, and the charter should say how we arrive at these decisions."

The proposed milestones are not present.

[Ballot block]
I have no general concern about chartering this WG but I would like to see a clarification with respect to this point:

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

Has there been any work or concerns discussed to see what's already out there, e.g., in the old ROHC WG (
https://datatracker.ietf.org/wg/rohc/charter/)?

Especially the documents describing how to do header compression for various levels in the protocol stack:
https://datatracker.ietf.org/wg/rohc/

[Ballot block]
This is a significant improvement, but a tighter definition of a constrained node needs to be provided than the one in the draft which simply points to a WG.

[Ballot comment]
I agree with Adrian that the draft shouldn't be main impetus for a charter.  If it is, then I think we can't charter this until the lwig terminology is actually approved and maybe even published.

In addition, I think the following could be tightened up:

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.

Maybe:

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

For #4, is there maintenance needed already or is that future proofing the charter?  Also, what information documents are needed - are there some already written?

a) It's just an example,  b) you don't actually need to list everything, and c) COMAN and SOLACE might not happen.

Also, isn't it s2.3 in draft-ietf-lwig-terminology that defines "Constrained Node Networks" not s2.1 and s2.2?

[Ballot comment]
I'm a No Objection. I understand Adrian's Discuss about using the LWIG draft to define the working group scope, but I'm assuming this will be addressed (whether by just using words like "constrained" in their normal sense, or by finding a more stable reference).

I'm not reading the current text as saying that "TCP over IPv6 over foo" would be in scope, but wonder whether using a term like "IPv6 encapsulation over foo" would be helpful in addressing Adrian's Comment.

[Ballot comment]
I'm a No Objection. I understand Adrian's discuss about using the LWIG draft to define the working group scope, but I'm assuming this can be addressed (whether by just using words like "constrained" in their normal sense, or by finding a more stable reference).

I don't think "TCP over IPv6 over foo" would be in scope, but wonder whether using a term like "IPv6 encapsulation over foo" would be helpful.

[Ballot 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 a something-over-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.

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

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