Definition of Managed Objects for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)
RFC 7388

Note: This ballot was opened for revision 03 and is now closed.

(Brian Haberman) Yes

(Jari Arkko) No Objection

Comment (2014-09-04 for -03)
No email
send info
Do not forget that the document needs a small change per Gen-ART review comments and as agreed in discussion.

(Alia Atlas) No Objection

(Richard Barnes) No Objection

(Benoît Claise) No Objection

Comment (2014-09-04 for -03)
No email
send info
For the record (this is a COMMENT, not a DISCUSS, even if I've been hesitating a lot), I'm not happy about the intended status of this document.
Note that this is in line with Adrian's COMMENT on why SNMP for constrained devices.

I was asked to provide my feedback a few months ago regarding the intended status, and was pushing for EXPERIMENTAL if the document organization remained the same.

First of all, the charter mentions:

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

So what is this document focusing on? An information model or a data model (read MIB module). As it is right now, clearly the latter.
This document could have focused on a information model, and providing the MIB module as an example. Such a document with title "Information Model Specification for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)" would be fine with PS intented status.

Second, will constrained devices be managed via SNMP? At this point in time I don't know, but my gut feeling tells me that it won't be the case.
So this document sends the wrong message to the industry.
It's true (http://www.ietf.org/mail-archive/web/6lo/current/msg00561.html) that:

    But as Jürgen pointed out correctly to me, the MIB module itself is just an API (similar to the IP MIB module), not necessarily tied to SNMP, and the data model itself is useful. 

This is a subtle way to say: I specify a MIB module, but consider it as an information model, so SNMP might not be used by constrained devices.
This is way too subtle. And yes, I've seen that sentence:

   While a MIB module provides a direct binding for accessing data via
   the Simple Network Management Protocol (SNMP) [RFC3410], supporting
   SNMP may not always be affordable on constrained devices.  Other
   protocols to access data modeled in MIB modules are possible and
   proposals have been made recently to provide bindings to the
   Constrained Application Protocol (CoAP) [RFC7252].


The two reasons why it's not a DISCUSS are
- Brian mentioned to me: "there was a discussion during the 6lo session in Toronto where the consensus changed on what the status should be."
- This set of counters is easy to map to a different data model language.

To summarize: unhappy about the intended status, but will not go against the WG consensus!

Alissa Cooper No Objection

Spencer Dawkins No Objection

Comment (2014-09-02 for -03)
No email
send info
I wondered the same thing Kathleen is wondering about devices that wouldn't be running SNMPv3.

I also wondered if there was any guidance for devices that don't run SMTP at all. 

If you choose to say anything about Kathleen's question, you might think about text that would also be applicable for a device being managed over CoAP.

(Adrian Farrel) No Objection

Comment (2014-09-01 for -03)
No email
send info
I have no objection to the publication of this document, but here are a few thoughts you might want to factor in before publication.

---

Of course, I have to ask the question: why a MIB module? As noted in the
Introduction, SNMP might not be a good choice in a constrained
environment and a different protocol might be used to carry MIB data. 
Why, if SNMP might be abandoned, do you continue to consider a MIB 
module instead of going straight to YANG? You presumably are dealing
with a new class of device that does not have SNMP or ASN.1 support.
I don't think that the previous MIB modules listed in Section 4 actually
provide justification because I doubt that this new class of device 
includes the MIB support as listed.

I suppose my question is really: Who has made the decision about how
objects will be managed in 6LowPANs? Is this a documented decision or
are we sleepwalking to MIB modules?

---
                 
Not sure "IMPORTS" should be in upper case in Section 5.

---

I don't think
       ORGANIZATION
           "Jacobs University Bremen"
is correct.
Maybe "IETF" or the 6lo working group?

---

       DESCRIPTION
           "Initial version, published as RFC XXXX."
       -- RFC Ed.: replace XXXX with RFC number and remove this note

       ::= { mib-2 XXXX }

You need an editor note for this second XXXX.
Of course, it would save some confusion if you used different letters 
for different meanings.

---

I don't find any discussion of wrapping. i know you have relatively low
throughput devices, but I consider a device with multiple interfaces and
that you have used counter32 (correctly, IMHO). One packet per second
would wrap at 136 years. So 12 packets per second on each of 12 
interfaces would wrap in one year (if my maths is working today).

IMHO you do not need larger counters, but you do need to add some text 
to describe wrapping and consider a discontinuity timer. (Actually, you
probably need a discontinuity timer anyway.)

(Stephen Farrell) No Objection

Comment (2014-09-04 for -03)
No email
send info
- Section 4 - is "typically used" for the CoAP etc stack in
Figure 1 really correct or a sort of wishful thinking?

- Figure 1 - why no RFC numbers on the left hand side?

- FWIW, Figure 2 doesn't tell me anything really. But not
suggesting you change unless there are loads of similarly
challenged folks in addition to me:-)

(Joel Jaeggli) No Objection

(Barry Leiba) No Objection

Comment (2014-09-02 for -03)
No email
send info
Tiny point: we're really trying to get away from "this memo" stuff... Can you call it "document" instead?

(Ted Lemon) No Objection

(Kathleen Moriarty) No Objection

Comment (2014-09-02 for -03)
No email
send info
I am fine with the security considerations of this draft, but do have a question.  Is it practical to have a strong recommendation for SNMPv3 for the constrained devices for which this draft is intended?  I of course like the considerations, but if it's not practical for SNMPv3 and the additional security provided to be enabled, that would be good to know.  If it is, that's great. Thanks.