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

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 1 Oct 2013 08:24:35 +0000

> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-
> university.de]
> Sent: Monday, September 30, 2013 3:01 PM
> To: Romascanu, Dan (Dan)
> Cc: Benoit Claise; [email-masked]; The IESG; 6lo WG
> Subject: Re: [6lo] [coman] WG Review: IPv6 over Networks of Resource-
> constrained Nodes (6lo)
> 
> On Fri, Sep 27, 2013 at 02:37:57PM +0000, Romascanu, Dan (Dan) wrote:
> > 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.
> >
> > My proposal was based on what you wrote in your previous mail:
> >
> > > 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.
> >
> > 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.
> >
> 
> 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.
> 

[[DR]] I agree with the argument made by Juergen in the PS. My personal preference is for a 'strict' charter wording for this WG for the development of the MIB module and a separate discussion (here or some place else) about the broader aspects of management of resource-constrained nodes. 

Regards,

Dan

---

From: joel jaeggli <[email-masked]>
Date: Wed, 2 Oct 2013 09:36:39 -0700

On Sep 30, 2013, at 5:01 AM, Juergen Schoenwaelder <[email-masked]> wrote:

>> 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. 
>> 
>>> 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.
>> 
>> 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. 
>> 
> 
> strict charter. It will at the end be the IESG's job to define what
> the IESG prefers.
> 

So, I'm of the opinion that the question isn't strict or open charter but rather that most work in this space doesn't use snmp for configuration, just instrumentation and that doesn't seem likely to change.

I like that text btw.

>    reasonable to me to use the same formalism also for the 6LoWPAN

yes they are and imho it does as well.

> 
> -- 
> 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: "Turner, Randy" <[email-masked]>
Date: Wed, 2 Oct 2013 16:59:45 +0000

I agree with Juergen's earlier comments regarding the use of SMIv2 -- seems like we would want to keep the same way of describing our data model.  But I would probably go a bit further.

I would pursue SMIv2/SNMP as a management infrastructure, and later, if something better comes along, someone can propose that.    SNMP management infrastructures (management stations, etc) are likely to be what we run into for managed LLNs, it would be nice if we what we come up with can play in those environments, without any loss of semantics or functionality.

Randy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of joel jaeggli
Sent: Wednesday, October 02, 2013 12:37 PM
To: Juergen Schoenwaelder
Cc: Benoit Claise; Romascanu, Dan (Dan); [email-masked]; The IESG; 6lo WG
Subject: Re: [coman] [6lo] WG Review: IPv6 over Networks of Resource-constrained Nodes (6lo)

I like that text btw.

P PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL.

This e-mail (including any attachments) is confidential and may be legally privileged. If you are not an intended recipient or an authorized representative of an intended recipient, you are prohibited from using, copying or distributing the information in this e-mail or its attachments. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete all copies of this message and any attachments. Thank you.

---

From: Benoit Claise <[email-masked]>
Date: Thu, 03 Oct 2013 10:33:15 +0200

Dear all,

Sorry for the delay in getting back to you.
I took the last email in the email threat to summarize my thoughts.

It seems that the latest proposal on the table is:

OLD:

   Related MIB modules

NEW:

It goes in the right direction, but it's not enough.
I would go for

   Information model for the counters in the 6LoWPAN layer for basic monitoring
   and troubleshooting, and a mapping to a data model (MIB module in this case)

Why?
- SNMP being the way to monitor counters on a constrained node now, I 
could buy that!
However, just telling "MIB modules" in the charter might give the wrong 
impression that SNMP is the only way to manage a constrained node. We 
don't know the answer at this point in time (at least, I don't)
- We really need to make the difference between information model and 
data model (RFC 3444)
Mapping from an information model to a different data model/protocol is 
the right way to go

Notes:
- the distinction between information model and data model doesn't imply 
that we need to have two deliverables.
- I'm in line with Dan regarding this comment "a separate discussion 
(here or some place else) about the broader aspects of management of 
resource-constrained nodes. "  This discussion should happen sometime, 
somewhere.

Regards, Benoit

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 3 Oct 2013 11:16:15 +0200

On Thu, Oct 03, 2013 at 10:33:15AM +0200, Benoit Claise wrote:
> 
> Why?
> - SNMP being the way to monitor counters on a constrained node now,
> I could buy that!
> However, just telling "MIB modules" in the charter might give the
> wrong impression that SNMP is the only way to manage a constrained
> node. We don't know the answer at this point in time (at least, I
> don't)
>
> - We really need to make the difference between information model
> and data model (RFC 3444)
> Mapping from an information model to a different data model/protocol
> is the right way to go
> 
> Notes:
> - the distinction between information model and data model doesn't
> imply that we need to have two deliverables.
> resource-constrained nodes. "  This discussion should happen
> sometime, somewhere.

It might help to look at what we are talking about here. The 'information
model' really is this Case Diagram:

                             IPv6 layer
                         ^               v
     InDelivers         -+-             -+-       OutRequests
                         |               |
     InDiscards       <--+               |
                         |               |
     InCompOKs       .-->|               |-->.    OutCompReqds
     InCompFails  <--|   |               |   +--> OutCompFails
     InCompReqds     `<--+               +<--'    OutCompOKs
                         |               |
                         |               +-->.    OutFragReqds
     InReasmOKs      .-->|               |   +--> OutFragFails
     InReasmFails <--|   |               |  -+-   OutFragOKs
     InReasmReqds    `<--+               +<--'    OutFragCreates
                         |               |
                         |               |
     InMeshDelivers      |<--.           |
     InMeshForwds        |   |-->.       |
     InMeshReceives      +-->'   |       |
                         |       +-->    |        OutMeshHopLimitExceeds
                         |       +-->    |        OutMeshNoRoutes
                         |       |       |
                         |       |   .<--+        OutMeshRequests
                         |       `-->|   |        OutMeshForwds
                         |           `-->|        OutMeshTransmits
                         |               |
     InHdrErrors      <--+               +-->     OutDiscards
                         |               |
     InReceives         -+-             -+-       OutTransmits
                         ^               v
                          interface layer

In the past, we simply recoded such things in MIB modules in the
'Overview' section and we were done.

So is your proposal that we s/Overview/Information Model/ ? Well,
if that is what is being called for...

/js

---

From: Benoit Claise <[email-masked]>
Date: Thu, 03 Oct 2013 11:44:40 +0200

Jürgen,
> if that is what is being called for...
I don't want to discuss the format or language for the information model 
here, but that would be a start. Yes.

I know that you know all about SNMP/MIB, NETCONF/YANG, Information/Data 
Model, and more, and that all this is clear in your mind. And I guess 
that you have your views on how to manage constrained devices: fine.

The issue I was trying to solve with, what could appear to be a trick to 
you (knowing your background), is sending the wrong message in a 
charter. And that message could/will be taken as granted by the rest of 
the pack.

Glad that we converge.

Regards, Benoit (OPS AD)

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 3 Oct 2013 11:53:09 +0200

>  and troubleshooting, and a mapping to a data model (MIB module in this case)

I still believe the parenthesis is a bit constraining (pun not intended), not the least because over time we will have more than one case.  (We also have at least one thing that actually is not a counter.)  More importantly, new IP-over-foos may need new counters, so limiting this to the 6LoWPAN layer means we'll need to recharter for a 6lobac MIB module etc.

For the ~ 10 % of work of the WG that is concerned with defining those counters (and related bits of information), the WG will need to listen for input from the management experts.

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.

Grüße, Carsten

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 3 Oct 2013 13:24:27 +0200

On Thu, Oct 03, 2013 at 11:44:40AM +0200, Benoit Claise wrote:

> I don't want to discuss the format or language for the information
> model here, but that would be a start. Yes.
> 
> I know that you know all about SNMP/MIB, NETCONF/YANG,
> Information/Data Model, and more, and that all this is clear in your
> mind. And I guess that you have your views on how to manage
> constrained devices: fine.
> 
> The issue I was trying to solve with, what could appear to be a
> trick to you (knowing your background), is sending the wrong message
> in a charter. And that message could/will be taken as granted by the
> rest of the pack.

My observation is that this protocol layer is rather simple and in the
past we did not ask for explicit information models for things that
are reasonably simple. But perhaps those times are over...

/js

---

From: Benoit Claise <[email-masked]>
Date: Thu, 03 Oct 2013 13:59:14 +0200

> are reasonably simple. But perhaps those times are over...
It's not black or white.
Constrained nodes are non traditional managed devices.

Regards, Benoit

---

From: Ulrich Herberg <[email-masked]>
Date: Thu, 3 Oct 2013 13:52:17 -0700

Carsten,

> I still believe the parenthesis is a bit constraining (pun not intended), not the least because over time we will have more than one case.  (We also have at least one thing that actually is not a c…

I agree with you on this point. It appears to me that we narrow down
the charter to a very small part of work, and we would end up
rechartering very soon, for example if a "6lobac" module is proposed.
Also, the proposed wording only includes counters; what about
read-write objects such as flags to provision objects? Would we want
to exclude that?

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

Yes.

Regarding Benoit's proposal of separating information and data module,
I am not sure whether this requires a separate deliverable; but as
Benoit said, this is not necessarily related, and could be a section
of, e.g., the 6lowpan MIB module. That could be part of the discussion
how to structure this once the WG is formed.

How about the following text:
- Information and data models (e.g., MIB modules) for these adaptation
layers for basic provisioning, monitoring and troubleshooting.

Best regards
Ulrich

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 3 Oct 2013 23:45:23 +0200

> layers for basic provisioning, monitoring and troubleshooting.

Strike provisioning; I don't think we know how to do this.

Grüße, Carsten

---

From: Ulrich Herberg <[email-masked]>
Date: Thu, 3 Oct 2013 16:32:31 -0700

> Strike provisioning; I don't think we know how to do this.

Maybe the term does not reflect what I meant. The previous proposal
used the word "counters" and "monitoring", and I wondered if that
would exclude "read-write" elements of a MIB module, such as for
setting a flag or other parameter.

Best regards
Ulrich

---

From: Benoit Claise <[email-masked]>
Date: Tue, 08 Oct 2013 22:20:46 +0200

> 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.
That makes sense to me.

Regards, Benoit

---

From: Benoit Claise <[email-masked]>
Date: Tue, 08 Oct 2013 22:39:40 +0200

> Strike provisioning; I don't think we know how to do this.
Works for me.

Regards, Benoit

---

From: Samita Chakrabarti <[email-masked]>
Date: Thu, 10 Oct 2013 02:14:43 +0000

Charter revision 04  removes "provisioning" .

-Samita

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Benoit Claise
Sent: Tuesday, October 08, 2013 1:40 PM
To: Carsten Bormann
Cc: [email-masked]; Ulrich Herberg; [email-masked]
Subject: Re: [coman] [6lo] WG Review: IPv6 over Networks of Resource-constrained Nodes (6lo)

On 3/10/2013 23:45, Carsten Bormann wrote:
>> - Information and data models (e.g., MIB modules) for these 
>> adaptation layers for basic provisioning, monitoring and troubleshooting.
Works for me.

Regards, Benoit

---

From: Benoit Claise <[email-masked]>
Date: Thu, 10 Oct 2013 09:21:12 +0200

> Charter revision 04  removes "provisioning" .
Even better: MIB module and provisioning is not an obvious match.

Regards, Benoit