Subject: Re: [coman] WG Review: IPv6 over Networks of Resource-constrained Nodes (6lo)

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 24 Sep 2013 12:47:53 +0000

Hi, 

I have a couple of issues with the way this charter is worded at this point, which makes the scope of the proposed WG unclear to me on some respects. 

1. There is careful wording about 'link layer technologies of interest' and about 'Security and management work that is not specific to the link layers being worked on is out of scope' - but no indication what are the criteria to identify these, or a list of initial such layer technologies. Is this completely open by now? Is there a process to discuss and select those? 

2. 'Selected MIB modules' - Did the team working on this proposal make any preparation work and determine that writing MIB modules is the appropriate way of meeting the manageability requirements for 6lo? If yes, where is this documented? If no, maybe this item should be worded in a more general manner and talk about requirements for managing the IP-over-foo specifications, followed by development of the appropriate information models and data models (the latest may be MIB modules, or may be something else). 

Thanks and Regards,

Dan

> -----Original Message-----
> From: [email-masked] [mailto:ietf-announce-
> [email-masked]] On Behalf Of The IESG
> Sent: Monday, September 23, 2013 9:02 PM
> To: IETF-Announce
> Cc: 6lo WG
> Subject: WG Review: IPv6 over Networks of Resource-constrained Nodes
> (6lo)
> 
> A new IETF working group has been proposed in the Internet Area. The
> IESG has not made any determination yet. The following draft charter was
> submitted, and is provided for informational purposes only. Please send
> your comments to the IESG mailing list (iesg at ietf.org) by 2013-10-03.
> 
>  IPv6 over Networks of Resource-constrained Nodes (6lo)
> ------------------------------------------------
> Current Status: Proposed WG
> 
> Chairs:
>   Ulrich Herberg <[email-masked]>
>   Samita Chakrabarti <[email-masked]>
> 
> Technical advisors:
>   Ralph Droms <[email-masked]>
> 
> Assigned Area Director:
>   Brian Haberman <[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
> 
> Charter:
> 
> 6lo focuses on Internet Area work that is needed for constrained node
> networks with the characteristics of:
> * limited power, memory and processing resources
> * hard upper bounds on state, code space and processing cycles
> * optimization of energy and network bandwidth usage
> * lack of some layer 2 services like complete device connectivity and
>   broadcast/multicast
> 
> Specifically, 6lo 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.
> 
> Only specifications targeting constrained node networks are in scope.
> 6lo will work closely with the 6man working group, which will continue
> to work on IP-over-foo documents outside the constrained node network
> space and will continue to be the focal point for IPv6 maintenance. For
> adaptation layer specifications that do not have implications on IPv6
> architecture, 6man will be notified about 6lo's working group last call.
> Specifications that might have such an impact (e.g., by using IPv6
> addresses in a specific way or by introducing new ND options) will be
> closely coordinated with 6man, and/or specific parts will be fanned out
> to 6man documents. Beyond 6man, 6lo will also coordinate with LWIG and
> INTAREA.
> 
> 6lo works on small, focused pieces of Internet Area work. 6lo does not
> take on larger cross-layer efforts. The working group will continue to
> reuse existing protocols and mechanisms whenever reasonable and
> possible.
> 
> 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).
> 
> Milestones:
> 
> TBD

---

From: Benoit Claise <[email-masked]>
Date: Tue, 24 Sep 2013 15:41:38 +0200

Hi,
> 2. 'Selected MIB modules' - Did the team working on this proposal make any preparation work and determine that writing MIB modules is the appropriate way of meeting the manageability requirements f…
I would add, for the 6lo people benefits, that 
http://tools.ietf.org/html/draft-ersue-constrained-mgmt-03 would be a 
good start.
Disclaimer: maybe this draft was mentioned already. I'm not following 
the 6lo mailing list.

Regards, Benoit
> _______________________________________________
> coman mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/coman
> .
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 24 Sep 2013 15:49:21 +0200

On Tue, Sep 24, 2013 at 03:41:38PM +0200, Benoit Claise wrote:
> http://tools.ietf.org/html/draft-ersue-constrained-mgmt-03 would be
> a good start.
> Disclaimer: maybe this draft was mentioned already. I'm not
> following the 6lo mailing list.

My understanding is that the charter refers to

http://tools.ietf.org/html/draft-schoenw-6lowpan-mib-03

and that it not aims at a general discussion about network management
of constrained devices. That is, it refers to concrete work instead of
abstract work.

/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: Benoit Claise <[email-masked]>
Date: Tue, 24 Sep 2013 16:07:15 +0200

> of constrained devices. That is, it refers to concrete work instead of
That's actually my point. Should we focus on developing a MIB module, 
taking for granting that SNMP is THE way to manage constrained nodes? Or 
should we ask ourselves: based on the collected management requirements, 
let's see what is more appropriate?
You know, like I2RS is currently doing, instead of jumping to 
NETCONF/YANG directly because it seemed like the solution.

Regards, Bneoit

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 24 Sep 2013 14:11:13 +0000

Exactly. The charter talks about 'related MIB modules'. Does this mean that the 'IPv6 over 6LoWPAN' MIB module applies to all 'link layer technologies of interest' and is all that is needed? 

Maybe all these aspects were discussed. However, when I see 'development of MIB modules' in the charter I feel we need to ask - is this what is required? 

Regards,

Dan

> From: Benoit Claise [mailto:[email-masked]]
> Sent: Tuesday, September 24, 2013 5:07 PM
> To: Romascanu, Dan (Dan); [email-masked]; The IESG; 6lo WG
> Subject: Re: [6lo] [coman] WG Review: IPv6 over Networks of Resource-
> constrained Nodes (6lo)
> 
> >>> I have a couple of issues with the way this charter is worded at
> this point, which makes the scope of the proposed WG unclear to me on
> some respects.
> >>>
> >>> 1. There is careful wording about 'link layer technologies of
> interest' and about 'Security and management work that is not specific
> to the link layers being worked on is out of scope' - but no indication
> what are the criteria to identify these, or a list of initial such layer
> technologies. Is this completely open by now? Is there a process to
> discuss and select those?
> >>>
> >>> 2. 'Selected MIB modules' - Did the team working on this proposal
> make any preparation work and determine that writing MIB modules is the
> appropriate way of meeting the manageability requirements for 6lo? If
> yes, where is this documented? If no, maybe this item should be worded
> in a more general manner and talk about requirements for managing the
> IP-over-foo specifications, followed by development of the appropriate
> information models and data models (the latest may be MIB modules, or
> may be something else).

---

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

Dan,

thank you for these comments. I think these are two important
questions. See below:

> 1. There is careful wording about 'link layer technologies of interest' and about 'Security and management work that is not specific to the link layers being worked on is out of scope' - but no ind…

Starting with an initial list of link layers (based on existing
drafts) is one option, but would make it rather hard to add other link
layers later, as it would require a recharter. I'd rather suggest to
precise the process of selecting technologies, based on the criteria
that are listed in the first paragraph of the current charter:

====================
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) for link layer technologies
of interest in constrained node networks. The process for selecting
the link-layer technologies will be based on WG consensus.
====================

Alternatively, we could further extend the criteria, e.g.:

====================
NEW
1. IPv6-over-foo adaptation layer specifications using 6LoWPAN
technologies (RFC4944, RFC6282, RFC6775) for link layer technologies
of interest in constrained node networks (i.e., that expose several of
the above criteria for constrained node networks). The process for
selecting the link-layer technologies will be based on WG consensus.
====================

> 2. 'Selected MIB modules' - Did the team working on this proposal make any preparation work and determine that writing MIB modules is the appropriate way of meeting the manageability requirements f…

This is a good point. I know the draft that Benoit cites well, and we
had intense discussions about management for constrained devices with
some of the people interested in "COMAN". At the last IETF there was a
COMAN discussion, which concluded (AFAIK) that MIBs are probably good
to keep as API (for compatibility and already existing work), but that
SNMP is likely not appropriate for constrained devices (at least not
as a general use case). I think that standardizing the 6lowpan MIB
would be useful, but we could make this bullet point more general and
not only focus on MIB modules. How about:

====================
OLD
2. Related MIB modules

NEW
2. Related interfaces for management applications (e.g., MIB modules)
====================

Best regards
Ulrich

---

From: Ulrich Herberg <[email-masked]>
Date: Wed, 25 Sep 2013 19:59:51 -0700

One additional comment to what Samita said:

<snip>
> That's actually my point. Should we focus on developing a MIB module, taking for granting that SNMP is THE way to manage constrained nodes? Or should we ask ourselves: based on the collected management requirements, let's see what is more appropriate?
> You know, like I2RS is currently doing, instead of jumping to NETCONF/YANG directly because it seemed like the solution.
>
>
> [SC>] We should discuss the scope of  management interfaces work in the wg meeting. Restricting to SNMP is certainly has its limitations.  Management configuration and reporting parameters requirements and Interfaces are important.  Personally, I'm in favor of a common architecture for the management infrastructure as much as possible for the 6lo devices and then leave hooks for L2-technology specific information.

UH> We had some discussion at the unofficial COMAN meeting last IETF
where agreed that MIBs are not necessarily tied to SNMP (although that
is currently the case). Peter van der Stok offered to work on a draft
that uses COAP for accessing a MIB module. I am not sure about the
status of that draft, but this is just to say that an interface is not
necessarily identical with the protocol accessing that interface.

Regards
Ulrich

---

From: Samita Chakrabarti <[email-masked]>
Date: Thu, 26 Sep 2013 01:47:05 +0000

Hi Benoit,

>> http://tools.ietf.org/html/draft-ersue-constrained-mgmt-03 would be a 
[SC>] 
[SC>] Thanks for pointing to this document  (Problem Statement, Usecases and Requirement on management of constrained nodes).
This is definitely a good start in understanding the problems and requirements.

>> Disclaimer: maybe this draft was mentioned already. I'm not following 
[SC>]  No, it is not currently listed in the milestones update.

> of constrained devices. That is, it refers to concrete work instead of 
[SC>] 
[SC>]  It is listed in the 6lo listinfo and proposed milestones for discussions.
              Of-course 6lo WG would decide if we want to define MIB only document and/or interfaces.

Best regards,
-Samita

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 26 Sep 2013 15:28:17 +0200

On Tue, Sep 24, 2013 at 04:07:15PM +0200, Benoit Claise wrote:
> That's actually my point. Should we focus on developing a MIB
> module, taking for granting that SNMP is THE way to manage
> constrained nodes? Or should we ask ourselves: based on the
> collected management requirements, let's see what is more
> appropriate?

One more time: The goal here is to define the number and the semantics
of the counters that need to implemented in the 6LoWPAN layer in order
to enable basic monitoring and troubleshooting. The formalism we have
(as a standard) for that are MIB modules.

There are several ways to transport the data over various protocols
today and there may be even more in the future. This activity is about
getting agreement what exactly needs to be counted where in the
6LoWPAN processing.

> NETCONF/YANG directly because it seemed like the solution.

If you believe this is needed here in order to define a bunch of
counters.

/js

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 26 Sep 2013 16:21:51 +0000

Hi, 

So instead of 'development of MIB modules' the charter should maybe say 'Information Model for the counters in the 6LoWPAN layer for basic monitoring and troubleshooting using SMIv2 MIB modules format'?

Regards,

Dan

> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-
> university.de]
> Sent: Thursday, September 26, 2013 4:28 PM
> To: Benoit Claise
> Cc: Romascanu, Dan (Dan); [email-masked]; The IESG; 6lo WG
> Subject: Re: [coman] [6lo] WG Review: IPv6 over Networks of Resource-
> constrained Nodes (6lo)
> 
> > >of constrained devices. That is, it refers to concrete work instead
> > >of abstract work.
> > taking for granting that SNMP is THE way to manage constrained nodes?
> > Or should we ask ourselves: based on the collected management
> > requirements, let's see what is more appropriate?
> 
> getting agreement what exactly needs to be counted where in the 6LoWPAN
> processing.
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 26 Sep 2013 23:52:21 +0200

> So instead of 'development of MIB modules' the charter should maybe say 'Information Model for the counters in the 6LoWPAN layer for basic monitoring and troubleshooting using SMIv2 MIB modules for…

You can argue for this but I believe this is not useful. We have ~20
years of MIB modules and frankly most of them (and in particular those
getting implemented) are focusing on statistics and counters. You can
now go into the direction of saying we stop doing this concrete down
to earth data modeling work and instead we do information models (in a
yet to be agree format). Is this going to help implementors? Is this
going to help people deploying stuff?

/js

---

From: Ulrich Herberg <[email-masked]>
Date: Thu, 26 Sep 2013 15:06:48 -0700

Jürgen, Dan,

in order to come to a quick conclusion about this charter item, can
you both indicate whether my proposed change would be acceptable? (or
propose something better?)

====================
OLD
2. Related MIB modules

NEW

That would immediately cover the 6lowpan MIB, but not necessarily
limit the scope to MIB modules.

Best regards
Ulrich

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 27 Sep 2013 00:18:14 +0200

> propose something better?)

This clearly is at the political layer. Within the IETF, we have SMIv2
to write MIB modules (~20 years of experience) and YANG to write YANG
modules (~2 (?) years of experience). Do you want an open ended
charter or something concrete? In fact, I would argue that it is not
6lo's charter item to invent how contrained networks are managed nor
is it their charter to define yet another data modeling approach.

Bottom line: Your suggested change is opening up how things are done
but I frankly do not see any/many choices I consider to be in scope of
6lo. (And hence I am not sure the change is helpful.)

/js

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 27 Sep 2013 08:58:02 +0200

On Sep 27, 2013, at 00:18, Juergen Schoenwaelder <[email-masked]> wrote:

> modules (~2 (?) years of experience).

Yes, and that's why it's pretty natural to do the 6LoWPAN MIB in SMIv2.

But it's not natural to decouple 6lo from further developments in the management data modeling space.

(It never occurred to me that "MIB modules" might be read to say "SMIv2 only", but now that you say it, it indeed can be interpreted in a narrow sense.)

> Do you want an open ended

Neither.  6lo's job is to do the data models based on its domain knowledge of the adaptation and link layers, not to do new data modeling approaches.
But if a new one becomes viable for constrained node networks, we shouldn't have to recharter to use it.

Now, on to the wording, maybe we can fix that:

NEW:
> 2. Related MIB modules (including, where applicable, management data models using other established IETF management data modeling schemes).

Grüße, Carsten

---

From: Samita Chakrabarti <[email-masked]>
Date: Fri, 27 Sep 2013 02:35:10 +0000

Hi Juergen,

Please see below inline.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
Sent: Thursday, September 26, 2013 3:18 PM
To: Ulrich Herberg
Cc: Benoit Claise; Romascanu, Dan (Dan); [email-masked]; The IESG; 6lo WG
Subject: Re: [6lo] [coman] WG Review: IPv6 over Networks of Resource-constrained Nodes (6lo)

> propose something better?)

This clearly is at the political layer. Within the IETF, we have SMIv2 to write MIB modules (~20 years of experience) and YANG to write YANG modules (~2 (?) years of experience). Do you want an open ended charter or something concrete? In fact, I would argue that it is not 6lo's charter item to invent how contrained networks are managed nor is it their charter to define yet another data modeling approach.
[SC>] 
[SC>] 

MIB models might be ~20 years old but 6lo or 6Lowpan did not exist then.
The above proposed change in the charter should cover MIB modules as well as other new approaches that are applicable for IOT devices and controllers.
I am not sure why 6lo should restrict itself to MIB only when the others in the industry are considering different types of modeling and interfaces.
I think the information model definition is a fine idea for applying to different types of implementations.

Thanks,
-Samita

---

From: Benoit Claise <[email-masked]>
Date: Fri, 27 Sep 2013 10:32:33 +0200

Jürgen,
> getting agreement what exactly needs to be counted where in the
Interesting.
And not point to say "one more time...", I only focus on the charter 
text, which is the contract between the IESG and WG.
When I read it:

	...
	2. Related MIB modules

How am I supposed to understand what you have in mind?
This specific entry has to improve.

Regards, Benoit

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Fri, 27 Sep 2013 14:37:57 +0000

Hi Juergen,

I believe that what would not be useful is to be vague in the charter about what the WG must develop as part of its 'contract' with the IESG. 

> (as a standard) for that are MIB modules.

Are now saying that the goal of the WG is not to define only the 'number and semantics of the counters' but actually the data model itself? Then Let us say it. I suggest: 

- MIB module for the counters in the 6LoWPAN layer for basic monitoring and troubleshooting

We should avoid just saying 'MIB module' because this is too vague, and also we should not imply that this is necessarily the full management solution because it seems that the discussion about what is the management solution did not yet happen in the WG. 

Regards,

Dan

> Sent: Friday, September 27, 2013 12:52 AM
> To: Romascanu, Dan (Dan)
> Cc: Benoit Claise; [email-masked]; The IESG; 6lo WG
> > So instead of 'development of MIB modules' the charter should maybe
> say 'Information Model for the counters in the 6LoWPAN layer for basic
> monitoring and troubleshooting using SMIv2 MIB modules format'?
> >
> 
> now go into the direction of saying we stop doing this concrete down to
> earth data modeling work and instead we do information models (in a yet
> to be agree format). Is this going to help implementors? Is this going
> to help people deploying stuff?
> 
> /js
> 
> --

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Fri, 27 Sep 2013 14:43:44 +0000

Hi Ulrich,

I believe that this proposal is even more vague. According to Juergen, the scope is specifically on a subset of the management solution specifically written in SMIv2. I believe that this subset (which may be what the operators need in a first phase) should be exactly described in the charter. A discussion broader discussion about a full management solution, or the management of constrained networks in general should happen separately in this WG or someplace else.

Regards,

Dan

> From: Ulrich Herberg [mailto:[email-masked]]
> Sent: Friday, September 27, 2013 1:07 AM
> To: Juergen Schoenwaelder; Romascanu, Dan (Dan); Benoit Claise;
> [email-masked]; The IESG; 6lo WG
> in order to come to a quick conclusion about this charter item, can you
> both indicate whether my proposed change would be acceptable? (or
> That would immediately cover the 6lowpan MIB, but not necessarily limit
> the scope to MIB modules.
> 
> Best regards
> Ulrich
> 
>

---

From: Ulrich Herberg <[email-masked]>
Date: Fri, 27 Sep 2013 10:04:05 -0700

Hi Dan,

the question is whether we want to limit the charter to the one single
draft that is currently proposed for this item (i.e., the 6lowpan MIB
module) and then require a recharter, or have a wider item (e.g.,
Carsten's proposal) that allows other, similar, drafts without
rechartering. Say there was a new proposal for a MIB module that does
not only have counters, but also allows setting some parameters. That
would be out of scope when using your definition and would require a
recharter. Or if there was a proposal to provide counters in the
6lowpan layer in YANG instead of SMIv2, then this would also be out of
scope.

Best regards
Ulrich

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 27 Sep 2013 10:44:37 -0700

>> 2. Related MIB modules (including, where applicable, management data models using other established IETF management data modeling schemes).

Carsten,

*If* the WG and the IESG want the broader scope, then I'd suggest 
explicitly mentioning Yang models instead of the "other established ..." 
wording. A key question would be whether such models would cover config 
and operational data.

A more radical approach would be to (gasp!), only do Yang even for 
operational data. It is easy to map Yang to a RESTful API (see 
draft-bierman-netconf-yang-api) which might fit nicely with CoAP.
But not doing SMIv2 models might be too radical?

    Erik

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 27 Sep 2013 20:43:11 +0200

On Sep 27, 2013, at 19:44, Erik Nordmark <[email-masked]> wrote:

> *If* the WG and the IESG want the broader scope, then I'd suggest explicitly mentioning Yang models instead of the "other established ..." wording.

Other management formats are out there, such as syslog, IPFIX, ...
Of course, we can recharter each time one of these becomes viable for constrained node networks.
I'm not qualified to say whether YANG will be our last data modeling scheme.
It seems more rational not to wire the specific set of management information models into the charter of one group that just happens to do some now and then.

> A key question would be whether such models would cover config and operational data.
> 
> A more radical approach would be to (gasp!), only do Yang even for operational data. It is easy to map Yang to a RESTful API (see draft-bierman-netconf-yang-api) which might fit nicely with CoAP.

I think that is really something that needs to be discussed both in this WG and in a broader operations/management perspective.  (It might be worthwhile to add a pointer to OPSAWG here.)
I'm not sure we need decisions before chartering 6lo.  (I'm not even sure we know the question we want decided.)

Grüße, Carsten

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 27 Sep 2013 16:54:17 -0700

> Other management formats are out there, such as syslog, IPFIX, ...

But those are protocols and not data models like SMIv2 or Yang.
E.g., IPFIX can *carry* structured information like SMIv2.

AFAIK IETF only has those two languages for data models.

> It seems more rational not to wire the specific set of management information models into the charter of one group that just happens to do some now and then.

It took the IETF order of 20 years to go from SMIv2 to Yang, and I sure 
hope 6lo is done before a third data model language is introduced in the 
IETF.

    Erik

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 30 Sep 2013 14:01:22 +0200

> We should avoid just saying 'MIB module' because this is too vague, and also we should not imply that this is necessarily the full management solution because it seems that the discussion about wha…

Apparently some prefer a more open ended charter while others prefer a
strict charter. It will at the end be the IESG's job to define what
the IESG prefers.

If a strict charter is called for, then replacing

  Related MIB modules

with

  MIB module for the counters in the 6LoWPAN layer for basic monitoring
  and troubleshooting

is certainly fine with me.

For those interested in a YANG model or a way to transport SMIv2 MIB
defined counters over CoAP, please read Appendix A:

  http://tools.ietf.org/html/draft-schoenw-6lowpan-mib-03#appendix-A

Following RFC 6643, a read-only MIB modules already translates into a
YANG module and this may lead to a JSON representation (although this
serialization of YANG defined data trees into JSON is at this point
unchartered work).

/js

PS: 6LoWPAN does not exist in isolation. There are further counters
    devices should support such as basic interface in/out counters or
    counters in the IPv6 layer. All these counters and their semantics
    are defined today in SMIv2 MIB modules. Hence, it seems quite
    reasonable to me to use the same formalism also for the 6LoWPAN
    layer.