[6lo] Intended status of draft-ietf-6lo-lowpan-mib

[Ulrich Herberg <[e-mail]>]

6lo WG,

(important: there is a question to the WG at the end of this email)

I put quite some thought on the intended status for the lowpan MIB
document in the last couple of weeks. I initially suggested it to be
Experimental
since it is unclear to me whether people will deploy it with SNMP. 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. Jürgen's slides
(http://www.ietf.org/proceedings/90/slides/slides-90-6lo-3.pdf)
show the positioning in the stack well, and Jürgen demonstrated his
implementation on constrained nodes at the plugfest
(http://www.ietf.org/proceedings/90/slides/slides-90-6lo-8.pdf). The
real "experiment" could be whether it will be used with SNMP, or via
something else (e.g., using the upcoming drafts for accessing
management data models via
draft-vanderstok-core-comi-04 or draft-ietf-netconf-restconf-01), but
this is out of the scope of the MIB document itself.
I also don't think that there are competing ways for what
is in this draft, where an argument could be that it's unclear which
of multiple ways of solving the same problem. So the only reason for
going experimental would be (in my opinion) if the WG is unsure
whether the draft
reflects the right set of counters. I have not heard any concerns
about the selection of the counters during the WGLC.

My suggestion therefore would be to:
  - keep the draft Std. Track

  - add a caveat (e.g., in the introduction) that in constrained
networks SNMP may not always be affordable (although there is at least
one implementation showing that it may work in some cases), but that a
MIB module itself is just a data model and therefore not necessarily
tied to SNMP, and that it could be used with other protocols (and
perhaps an informative
reference to draft-vanderstok-core-comi?). Maybe one could also add
a description of how this MIB module fits into the IoT stack, describing
what Jürgen shows in his slides.

- update reference to the latest btle revision

- requesting publication shortly after Toronto

In addition, I also suggest to:
 - remove appendix A (JSON representation). This is non-normative, and
relies on an expired individual draft of how to represent JSON with
YANG. Either this should be normative (in which case it probably
should be its own RFC with proper normative references), or it should
not be part of this standards track document (in my opinion). Since
this is non-normative, I could live with this paragraph, but
I just don't see the value. Jürgen pointed out to me that the YANG to
JSON mapping is an active WG item in NETMOD these days, so maybe using
another reference would at least avoid the problem with the expired
individual reference.



My question to the WG is:
Does anyone object with publishing this as Std. Track?

During the meeting tomorrow, I will ask the same question, giving
everyone the opportunity to voice concerns with this.

Please also consider my proposal to add the caveat and to remove the appendix.


Best regards
Ulrich