Subject: [6lo] Focusing the charter

From: Carsten Bormann <[email-masked]>
Date: Sat, 1 Jun 2013 14:44:12 +0200

Welcome again to the 6Lo mailing list.

We now have 62 email addresses on the list.

Most of you will have read the 6Lo list announcement message:

  http://www.ietf.org/mail-archive/web/ietf-announce/current/msg11531.html

Please do reread it if you wonder about the objectives of this mailing
list, and why it might be a good idea to create a working group
focusing on Internet Area issues in IPv6 over constrained node
networks.

Work is ongoing in this field.  Some of the drafts listed in the above
message have been updated since the list was made (including lowpanz,
ghc, and alfi, as well as the roadmap), and, just yesterday, yet
another new draft was posted that might be of interest:
draft-raza-6lowpan-ipsec-00.txt.

I would now like to start the discussion of a potential 6Lo charter
with some draft text snippets for what the WG will do.
Introductory text, as well as some boilerplate, can be added later.

The charter is the document that focuses the WG on a specific subject
area, and we should be careful to make that focus neither too narrow
nor too wide.  There are a number of other activities in constrained
node networks in the IETF, most of which happens in other IETF areas,
and it is much better to interface with this work than to give the
impression there will be unclear boundaries and overlap.  We also want
to focus on work that the IETF is good in.  So this is not a shopping
list, but on the other hand, if something is missing, we need to add
it, and if something is unclear, we need to fix it.

Grüße, Carsten

6Lo focuses on INT area work that is needed for constrained node networks.
Specifically, it is working on
-- adaptation layer specifications for link layer technologies of
   interest in constrained node networks;
-- related MIBs;
-- common infrastructure specification such as header compression
   specific to constrained node networks;
-- maintenance and informational documents required for the existing
   IETF specifications in this space.

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

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 14 Jun 2013 15:02:37 +0200

On Jun 1, 2013, at 14:44, Carsten Bormann <[email-masked]> wrote:

> [...]

On a mailing list, when there is a period of quiet after a suggestion, it is sometimes hard to find out whether

1) everybody, of course, agrees, and that is so obvious that it needs no saying,
2) everybody is annoyed by the idiot that made the suggestion, and nobody wants to give it more attention than it is worth by pointing out the obvious flaws,
3) nobody cares,
4) __________________ (fill in the blanks)

Can you give a quick 1/2/3/4?

Also, there were two suggestions outside this thread:

-- Behcet would like to include secure bootstrapping in the focus of the group.
   I think I have already explained that I have mixed experience with that, 
   and that I would like to focus on the IP-over-foo documents and common infrastructure they may need.
   However, some IP-over-foo may need to interact with the network keying going on at the foo layer.
   On the other hand, there is also a BOF brewing on adapting DTLS for constrained node networks.
   So if you have some specific work you think that needs to be done 
   to make a 6LoWPAN-like network work, we probably need to hear about it.

-- I received an off-list comment that it might be a good idea to do some more generic 
   architecture work on low-power adaptation.  Again, I'm a bit skeptical that we can muster the energy.
   So far, we seem to have worked well by addressing one technology at a time.
   On the other hand, 6LoWPAN-ND definitely has had its own share of architecture work, 
   and if there is a need to do more, we should discuss this.
   (Strictly speaking, drafts like draft-bormann-intarea-alfi-02 or 
   draft-thubert-6lowpan-backbone-router-03 also include some architecture work.)

It would be good if we could get a number of yays/nays for the general direction of charter proposal and input on the above specific points (or any other that need discussion) in the next couple of days here on this list; the IESG will need to decide next week whether to hold this BOF in Berlin or not.

Grüße, Carsten

---

From: Ralph Droms <[email-masked]>
Date: Fri, 14 Jun 2013 09:08:38 -0400

An important follow-up: Ulrich Herberg has agreed to co-chair the BoF, and I've added his name to the BoF Request.  Thanks, Ulrich.

As suggested, I've added draft-sarikaya-6lo-bootstrapping-solution-00 to the list of drafts potentially in the 6lo charter.  There may have been one other draft suggested for the list that I missed?

As Carsten requested, please review the charter and BoF request and respond here with comments.

- Ralph

---

From: Michael Richardson <[email-masked]>
Date: Fri, 14 Jun 2013 09:17:03 -0400

Carsten Bormann <[email-masked]> wrote:
    CB> On Jun 1, 2013, at 14:44, Carsten Bormann <[email-masked]> wrote:

    >> 6Lo focuses on INT area work that is needed for constrained node
    >> networks.  [...]

    CB> On a mailing list, when there is a period of quiet after a
    CB> suggestion, it is sometimes hard to find out whether

I admit to being confused... why did we close 6lowpan again?
Why not just re-open it with a new charter?

    CB> Also, there were two suggestions outside this thread:

    CB> -- Behcet would like to include secure bootstrapping in the focus of
    CB> the group.  I think I have already explained that I have mixed
    CB> experience with that, and that I would like to focus on the
    CB> IP-over-foo documents and common infrastructure they may need.

    CB> However, some IP-over-foo may need to interact with the network
    CB> keying going on at the foo layer.  On the other hand, there is also a
    CB> BOF brewing on adapting DTLS for constrained node networks.  So if
    CB> you have some specific work you think that needs to be done to make a
    CB> 6LoWPAN-like network work, we probably need to hear about it.

1) the work needs to be done.

2) it is intimately related to getting on the network, and IP-over-FOO
   documents have in the past blissfully ignored this, to their peril,
   in my opinion.

3) (One of the reasons IP is successful is the extremely lose relationship
   and completely lack of channel binding between layer 2 and layer 3.
   Imagine how badly IPv4 would have flourished if ARP had looked like
   SEND on day 1, or if PANA-EAP-TLS-with-verisign-cert had been required?)

So I share your concern.  I think that this is a KARP-like thing.
I question whether we need 6lo and the DTLS group.   I think that is easier
to just ask for two 2 hour slots for one group, than to ask for a 2.5
hour slot for each of two groups of the same people.

    CB> -- I received an off-list comment that it might be a good idea to do
    CB> some more generic architecture work on low-power adaptation.  Again,
    CB> I'm a bit skeptical that we can muster the energy.  So far, we seem
    CB> to have worked well by addressing one technology at a time.  On the

And this would differ from lwig how?

And 6tsch is also likely to proceed.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 14 Jun 2013 16:08:24 +0200

> Why not just re-open it with a new charter?

6LoWPAN was focused on getting IPv6 working on top of IEEE 802.15.4.
That work is done, and the IETF tends to close WGs when their work is done.

I think what we are trying to do here is define that new charter, and there is little difference in whether this is a new group or an old group continuing with a quite different charter.

> So I share your concern.  I think that this is a KARP-like thing.

Sounds like trouble :-)

> hour slot for each of two groups of the same people.

I'm not sure it's the same people.  DICE people would be (or inevitably become) TLS experts. 
Little of that is needed in 6lo.  (Of course, GHC was designed to compensate for some of DTLS's garrulity problem, but you don't need to understand DTLS's security properties to understand how header compression for it works.)

6lo would be the place where people who care about specific radios would meet with people who build adaptation layers and provide INT area common infrastructure for that.  
The fact that some "IoT" people are generalists who work on multiple layers to make IoT happen doesn't mean everybody in these WGs has to be like that.

> And this would differ from lwig how?

LWIG documents how to implement the existing architecture.

This potential work would move the architecture forward.
E.g., how can IPv6 flourish in a world where multicast doesn't work very well because many nodes are sleeping most of the time, where the classical host-router dichotomy may need some updates, where multiple layers of IP routing are interacting, some of which are operating within a subnet.
(But I would like to know more about what that work would encompass before advocating it.)

> And 6tsch is also likely to proceed.

6tsch is a more narrowly focused undertaking that wants to make use of some newly standardized radio technology (TSCH mode of IEEE 802.15.4e) to build more deterministic forwarding systems.  Interesting work, but as a whole with more far-reaching implications on architecture for a more narrow set of applications.

And there is a proposal for an "its" BOF, which I don't quite understand yet, but may be related.

Grüße, Carsten

---

From: Ulrich Herberg <[email-masked]>
Date: Fri, 14 Jun 2013 08:21:22 -0700

Hi,

I am in favor of having a BOF, and I believe that the proposed charter
is a good starting point. Some comments below:

On Fri, Jun 14, 2013 at 6:02 AM, Carsten Bormann <[email-masked]> wrote:
[...]
>    to make a 6LoWPAN-like network work, we probably need to hear about it.

I agree with Carsten. We need to make sure that there is no overlap
with other BOFs/WGs.

>    draft-thubert-6lowpan-backbone-router-03 also include some architecture work.)

I am skeptical about defining "more generic architecture". (I admit
that I am still burned by AUTOCONF, which ended in a painful death
talking only about architecture).

> It would be good if we could get a number of yays/nays for the general direction of charter proposal and input on the above specific points (or any other that need discussion) in the next couple of…

Regarding the list of drafts that Carsten compiled:
I believe that the IP-over-foo drafts are definitely important. It
would be good to
discuss the use cases for each of the drafts to understand the level of
community interest.

The 6lowpan MIB may be useful, even though I am still wondering how
SNMP can be used over link layers using 6lowpan (a discussion that was
also started in COMAN). Maybe the MIB could be used by future
management protocols for constrained devices (that I still think the
IETF is missing).

Header compression can be very useful, and I think relevant to those
link layers that have a small MTU or are otherwise constrained.

I am a bit concerned about
draft-kelsey-intarea-mesh-link-establishment, which I remember I read
when it was posted on the MANET mailing list. There were some review comments
that the same functionality could be achieved with RFC6130 (NHDP). It may need
further discussions to see if there is a unique use case and if it's
the best way to achieve what is intended.

I'll have to read Pascal's draft about the Backbone router in more
detail to get an opinion if the concept is the right approach. I think
that there is a use case for dividing several LLNs via backbone
routers for reasons of scalability, flexibility and manageability. But
it has to be done careful, in particular I am skeptical about
things like multi-link subnets on L3.

Talking about fragmentation is interesting and useful, in
particular when mesh-under routing is used (as specified in section 11
of RFC4944).

One more things I had in mind:
Section 11 of RFC4944 mentions the use of mesh-under routing. But
there is no end-to-end security of 6lowpan mesh headers defined (nor
is there any mesh-under routing protocol for 6lowpan for that matter).
I don't know if there is any intention in the IETF to complete this
what has been started in 4944, or if that would be out of scope for
IETF.

Best regards
Ulrich

---

From: Michael Richardson <[email-masked]>
Date: Fri, 14 Jun 2013 13:38:50 -0400

>>>>> "Carsten" == Carsten Bormann <[email-masked]> writes:
    >> I admit to being confused... why did we close 6lowpan again?  Why
    >> not just re-open it with a new charter?

    Carsten> 6LoWPAN was focused on getting IPv6 working on top of IEEE
    Carsten> 802.15.4.  That work is done, and the IETF tends to close
    Carsten> WGs when their work is done.

I didn't think it was exclusive to 15.4, but rather to low power links
that had too small MTUs.

So, the small-MTU problem being solved, we move on.
What in the end does the "l" and "o" in 6lo mean?

    >> So I share your concern.  I think that this is a KARP-like thing.

    Carsten> Sounds like trouble :-)

My point is that KARP is a Routing Area WG doing security work.
I think that if 6lo is doing secure join, it's just fine that it occur
in INT.  Further, secure join it seems likely that TLS (in EAP or DTLS
forms) is going to be involved, and tweaks to *TLS will occur.

    >> I question whether we need 6lo and the DTLS group.  I think that
    >> is easier to just ask for two 2 hour slots for one group, than to
    >> ask for a 2.5 hour slot for each of two groups of the same
    >> people.

    Carsten> I'm not sure it's the same people.  DICE people would be
    Carsten> (or inevitably become) TLS experts. Little of that is

We might not start with the same people, but if we don't wind up with
a group of people having a single conversation, (and agreeing to a set
of design compromises) then we will fail.

    >> And 6tsch is also likely to proceed.

    Carsten> 6tsch is a more narrowly focused undertaking that wants to
    Carsten> make use of some newly standardized radio technology (TSCH
    Carsten> mode of IEEE 802.15.4e) to build more deterministic

I'm pointing out 6tsch, not because it is overlapping, but because there
are a finite number of WGs that the IETF can support.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 14 Jun 2013 13:42:11 -0400

>>>>> "Ulrich" == Ulrich Herberg <[email-masked]> writes:
    Ulrich> The 6lowpan MIB may be useful, even though I am still
    Ulrich> wondering how SNMP can be used over link layers using
    Ulrich> 6lowpan (a discussion that was also started in COMAN). Maybe

MIBs are not SNMP.
MIBs are a set of well defined counters (and other objects) defined in ASN.1.
SNMP is just one way of transporting queries about that ASN.1.

We could use CoAP, for instance.

    Ulrich> One more things I had in mind: Section 11 of RFC4944
    Ulrich> mentions the use of mesh-under routing. But there is no
    Ulrich> end-to-end security of 6lowpan mesh headers defined (nor is
    Ulrich> there any mesh-under routing protocol for 6lowpan for that
    Ulrich> matter).  I don't know if there is any intention in the IETF
    Ulrich> to complete this what has been started in 4944, or if that
    Ulrich> would be out of scope for IETF.

If the mesh is under, then the security has to be under too.
Secure joining of mesh under implies a layer-2 bootstrap operation.
If layer-3 protocols are necessary to do that, then one needs to run a
second (unsecured) mesh-under.  
(PANA is a layer-2 way to carry EAP, so doesn't require a layer-3+)

---

From: Ulrich Herberg <[email-masked]>
Date: Fri, 14 Jun 2013 10:53:45 -0700

Michael,

> SNMP is just one way of transporting queries about that ASN.1.

I know. But are MIBs used by any protocol (in practice) other than SNMP?

> We could use CoAP, for instance.

I agree, and that's what I wanted to say in my initial post. Such
usage of MIBs with COAP is not specified AFAIK.

> If the mesh is under, then the security has to be under too.

I agree.

Best regards
Ulrich

---

From: Michael Richardson <[email-masked]>
Date: Fri, 14 Jun 2013 14:13:09 -0400

>> MIBs are not SNMP.  MIBs are a set of well defined counters (and
    >> other objects) defined in ASN.1.  SNMP is just one way of
    >> transporting queries about that ASN.1.

    Ulrich> I know. But are MIBs used by any protocol (in practice)
    Ulrich> other than SNMP?

NETCONF calls it's model YANG. (RFC6020)
The important part of a "MIB" discussion is not whether it's Counter32
or module foo{}.  

The important thing is that we agree on whether we are counting bytes or
packets for a particular counter, and if bytes, whether it includes the
layer-2 overhead or not.

---

From: Geoff Mulligan <[email-masked]>
Date: Fri, 14 Jun 2013 12:14:26 -0600

> SNMP is just one way of transporting queries about that ASN.1.
Ulrich: Why can't SNMP be used over 6lowpans?  I don't see what would 
technically stop it from being used or from working.

---

From: Geoff Mulligan <[email-masked]>
Date: Fri, 14 Jun 2013 12:15:45 -0600

PS - I do support the idea of this BoF and I like the direction.

On 06/14/2013 12:14 PM, Geoff Mulligan wrote:
> _______________________________________________
> 6lo mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lo

---

From: Ulrich Herberg <[email-masked]>
Date: Fri, 14 Jun 2013 11:21:31 -0700

Geoff,

> technically stop it from being used or from working.

That is an interesting question that (I think) was part of a
to-be-done gap analysis in the COMAN draft. The main question would be
if SNMP has too much overhead for constrained devices and networks
(both in terms of payload and stack size). Has anyone deployed SNMP in
such networks and on constrained devices?

Best regards
Ulrich

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 14 Jun 2013 20:22:42 +0200

On Jun 14, 2013, at 20:14, Geoff Mulligan <[email-masked]> wrote:

> Ulrich: Why can't SNMP be used over 6lowpans?  I don't see what would technically stop it from being used or from working.

I'm not Ulrich, but the answer is that it sure can (as Juergen has demonstrated amply).

But is it the right protocol for energy-sensitive systems?
(And, if not, is CoAP?)

That is something that COMAN has already invested a lot of work in, and I urge people who are interested in this to look at the COMAN drafts, draft-ersue-constrained-mgmt-03.txt for the requirements and draft-greevenbosch-coman-candidate-tech-02.txt for a first round at mapping the requirements to protocols.

COMAN is outside the scope of 6lo.

As Michael mentioned, agreeing the semantics of specific measurement points, i.e. what to count, can be done relatively independent of this work.
As proposed, this part is inside of 6lo, as it has been for most IP-over-foo efforts.

Grüße, Carsten

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 14 Jun 2013 22:04:21 +0200

> focusing on Internet Area issues in IPv6 over constrained node

I generally support the direction and the overall scope of the work
and hence having a BoF.

The organizational question, namely over how many WGs in which areas
IoT related work should be spread, I can't really answer but it seems
the 6lo work is rather distinct from very DTLS specific security
work. There are several possible options, e.g.

- charter DICE and 6LO (as proposed) and run them next to LWIG and
  ROLL and CoAP (and any other IoT WG to come along in the future,
  i.e. giving each WG a very specific task and short duration - at
  least in theory)

- charter DICE, merge 6LO with LWIG, leave ROLL and CoAP as they are

- merge DICE work into the TLS WG, merge 6LO and perhaps even LWIG
  work into the 6MAN WG, leave ROLL and CoAP as they are

but I probably need a BoF to form a more clear opinion what makes
sense from an organizational point of view.

/js

-- 
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: Geoff Mulligan <[email-masked]>
Date: Fri, 14 Jun 2013 15:49:00 -0600

> such networks and on constrained devices?
In my experience with implementing SNMP and also working with folks that 
have done an SNMP like protocol, it is certainly doable to implement and 
use it with constrained devices and networks.  In my implementation I 
did not provide a full ASN.1 compliant system, but instead only 
implemented a limited set of BER to improve stack size and I elided some 
of the OID to improve payload efficiency.

NXP's JennetIP implements a protocol that is similar to SNMP.

So, no I don't think that SNMP would have too much overhead for these 
devices and networks and I'm still interested in pursuing this.

     geoff

---

From: Ulrich Herberg <[email-masked]>
Date: Fri, 14 Jun 2013 15:00:07 -0700

Thanks for this information!

Best regards
Ulrich

On Fri, Jun 14, 2013 at 2:49 PM, Geoff Mulligan <[email-masked]> wrote:
> have done an SNMP like protocol, it is certainly doable to implement and use
> it with constrained devices and networks.  In my implementation I did not
> provide a full ASN.1 compliant system, but instead only implemented a
> limited set of BER to improve stack size and I elided some of the OID to
> improve payload efficiency.
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 15 Jun 2013 09:14:00 +0200

On Fri, Jun 14, 2013 at 03:49:00PM -0600, Geoff Mulligan wrote:
> In my experience with implementing SNMP and also working with folks
> that have done an SNMP like protocol, it is certainly doable to
> implement and use it with constrained devices and networks.  In my
> implementation I did not provide a full ASN.1 compliant system, but
> instead only implemented a limited set of BER to improve stack size
> and I elided some of the OID to improve payload efficiency.

For those interested, here are the details of our SNMP implementation
running on Contiki (and we also share the code):

    http://cnds.eecs.jacobs-university.de/software/contiki-snmp/

That said, I agree with an earlier statement that MIB modules are
primarily needed in order to agree on the semantics of counters that
should become part of IoT protocol implementations so that the
counters have well defined semantics and are comparable.

/js

---

From: Ulrich Herberg <[email-masked]>
Date: Sun, 16 Jun 2013 18:41:08 -0700

Thanks.

Ulrich

On Sunday, June 16, 2013, wrote:

>
> >>>>> "Ulrich" == Ulrich Herberg <[email-masked] <javascript:;>>
> writes:
>     Ulrich> On Fri, Jun 14, 2013 at 11:14 AM, Geoff Mulligan
>     Ulrich> <[email-masked] <javascript:;>> wrote:
>
>     >> Ulrich: Why can't SNMP be used over 6lowpans?  I don't see what
>     >> would technically stop it from being used or from working.
>
>     Ulrich> That is an interesting question that (I think) was part of a
>     Ulrich> to-be-done gap analysis in the COMAN draft. The main
>     Ulrich> question would be if SNMP has too much overhead for
>
> please read: https://datatracker.ietf.org/doc/draft-sehgal-roll-rpl-mib/
>
> The authors report implementing this in Contiki already.
>
> --
> ]     [email-masked] <javascript:;>  http://www.sandelman.ca/        |
>   ruby on rails    [
>
>

---

From: [email-masked]
Date: Sun, 16 Jun 2013 20:36:50 -0400

---

From: Emmanuel Baccelli <[email-masked]>
Date: Mon, 17 Jun 2013 11:06:09 +0200

Hi Carsten,
I support the idea of a 6lo BoF based on this draft of charter.
Best,
Emmanuel

On Fri, Jun 14, 2013 at 3:09 PM, Ralph Droms <[email-masked]> wrote:

> An important follow-up: Ulrich Herberg has agreed to co-chair the BoF, and
> I've added his name to the BoF Request.  Thanks, Ulrich.
>
> As suggested, I've added draft-sarikaya-6lo-bootstrapping-solution-00 to
> the list of drafts potentially in the 6lo charter.  There may have been one
> other draft suggested for the list that I missed?
>

---

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Mon, 17 Jun 2013 14:00:34 +0200

Hi Carsten,

IMO the 6lo effort is really needed for the reasons already stated (e.g.
in the 6lo Info Page).

I support and plan to attend the (possible) BOF in Berlin.

Greetings,

Carles

> 2) everybody is annoyed by the idiot that made the suggestion, and nobody
> wants to give it more attention than it is worth by pointing out the
> obvious flaws,
> 3) nobody cares,
> It would be good if we could get a number of yays/nays for the general
> direction of charter proposal and input on the above specific points (or
> any other that need discussion) in the next couple of days here on this
> list; the IESG will need to decide next week whether to hold this BOF in
> Berlin or not.
>
> Grüße, Carsten
>

---

From: "JP Vasseur (jvasseur)" <[email-masked]>
Date: Thu, 20 Jun 2013 17:54:20 +0000

Hi,

I see a number of topics being discussed that may lead to a wide charter ... who "owns" the latest revision ?

Thanks.

JP.

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 20 Jun 2013 23:36:07 +0200

Hi JP,

> I see a number of topics being discussed that may lead to a wide charter ...

I hope not...

> who "owns" the latest revision ?

The proposed text for the charter is at

	https://github.com/6lo/charter

There have been no changes so far since I started this thread on June 1st.

Please feel free to fork and send pull requests, and/or comment here.
(Discussion should preferably be here on the mailing list.)

Grüße, Carsten