Definition of Managed Objects for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)
draft-ietf-6lo-lowpan-mib-04
Yes
(Brian Haberman)
No Objection
(Alia Atlas)
(Alissa Cooper)
(Joel Jaeggli)
(Richard Barnes)
(Ted Lemon)
Note: This ballot was opened for revision 03 and is now closed.
Brian Haberman Former IESG member
Yes
Yes
(for -03)
Unknown
Adrian Farrel Former IESG member
No Objection
No Objection
(2014-09-01 for -03)
Unknown
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.)
Alia Atlas Former IESG member
No Objection
No Objection
(for -03)
Unknown
Alissa Cooper Former IESG member
No Objection
No Objection
(for -03)
Unknown
Barry Leiba Former IESG member
No Objection
No Objection
(2014-09-02 for -03)
Unknown
Tiny point: we're really trying to get away from "this memo" stuff... Can you call it "document" instead?
Benoît Claise Former IESG member
No Objection
No Objection
(2014-09-04 for -03)
Unknown
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!
Jari Arkko Former IESG member
No Objection
No Objection
(2014-09-04 for -03)
Unknown
Do not forget that the document needs a small change per Gen-ART review comments and as agreed in discussion.
Joel Jaeggli Former IESG member
No Objection
No Objection
(for -03)
Unknown
Kathleen Moriarty Former IESG member
No Objection
No Objection
(2014-09-02 for -03)
Unknown
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.
Richard Barnes Former IESG member
No Objection
No Objection
(for -03)
Unknown
Spencer Dawkins Former IESG member
No Objection
No Objection
(2014-09-02 for -03)
Unknown
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.
Stephen Farrell Former IESG member
No Objection
No Objection
(2014-09-04 for -03)
Unknown
- 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:-)
Ted Lemon Former IESG member
No Objection
No Objection
(for -03)
Unknown