IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals
draft-ietf-6lowpan-problem-08

[Ballot discuss]
The sections related to management and operational deployment are quite vague, contradictory, and do not draw the appropriate and workable goals.

One one hand Section 4.4 seems to drive towards the use of automatic bootstrap and minimal or zero configuration operations:

  As alluded to above, devices within LoWPANs are expected to be
  deployed in exceedingly large numbers.  Additionally, they are
  expected to have limited display and input capabilities.
  Furthermore, the location of some of these devices may be hard to
  reach.  Accordingly, protocols used in LoWPANs should have minimal
  configuration, preferably work "out of the box", be easy to
  bootstrap, and enable the network to self heal given the inherent
  unreliable characteristic of these devices.  Network management
  should have little overhead yet be powerful enough to control dense
  deployment of devices.

On the other hand Goal #5 in Section 5 recommends:

      Network Management: One of the points of transmitting IPv6
      packets, is to reuse existing protocols as much as possible.
      Network management functionality is critical for LoWPANs.
      [RFC3411] specifies SNMPv3 protocol operations.  SNMP
      functionality may be translated "as is" to LoWPANs.  However,
      further investigation is required to determine if it is suitable,
      or if an appropriate adaption is in order.  This adaptation could
      include limiting the data types and simplifying the Basic
      Encoding Rules so as to reduce the size and complexity of the
      ASN.1 parser, thereby reducing the memory and processing needs to
      better fit into the limited memory and power of LoWPAN devices.

I do not believe that this recommendation is valid. On one hand SNMP may not be the appropriate protocol to use in this environment if the goal is to reach a degree of automatic bootstrap, minimal configuration and self-healing. On the other hand assuming SNMP will be used, standardizing a subset of SNMP or SMI for 6lowpan purposes does not seem the appropriate thing to do - this WG or other organizations involved with this technology would not have the expertise to do it, and doing it may not result in the desired effects.

I would suggest to re-write these paragraphs so that they include a more clear definition of the operational modes and requirements for management in 6lowpan deployments, what are the resources that need to be controlled on the devices and in the protocol (message size for example) and from here to derive requirements for the protocols to be used without specifying any protocol at this phase. Selection of the protocol or protocols that can meet the manageability and operational requirements for 6lowpan should make the object of later work.

[Ballot discuss]
The sections related to management and operational deployment are quite vague, contradictory, and do not draw the appropriate and workable goals.

One one hand Section 4.4 seems to drive towards the use of automatic bootstrap and minimal or zero configuration operations:

  As alluded to above, devices within LoWPANs are expected to be
  deployed in exceedingly large numbers.  Additionally, they are
  expected to have limited display and input capabilities.
  Furthermore, the location of some of these devices may be hard to
  reach.  Accordingly, protocols used in LoWPANs should have minimal
  configuration, preferably work "out of the box", be easy to
  bootstrap, and enable the network to self heal given the inherent
  unreliable characteristic of these devices.  Network management
  should have little overhead yet be powerful enough to control dense
  deployment of devices.

On the other hand Goal #5 in Section 5 recommends:

      Network Management: One of the points of transmitting IPv6
      packets, is to reuse existing protocols as much as possible.
      Network management functionality is critical for LoWPANs.
      [RFC3411] specifies SNMPv3 protocol operations.  SNMP
      functionality may be translated "as is" to LoWPANs.  However,
      further investigation is required to determine if it is suitable,
      or if an appropriate adaption is in order.  This adaptation could
      include limiting the data types and simplifying the Basic
      Encoding Rules so as to reduce the size and complexity of the
      ASN.1 parser, thereby reducing the memory and processing needs to
      better fit into the limited memory and power of LoWPAN devices.

I do not believe that this recommendation is valid. On one hand SNMP may not be the appropriate protocol to use in this environment if the goal is to reach a degree of automatic bootstrap, minimal configuration and self-healing. On the other hand assuming SNMP will be used, standardizing a subset of SNMP or SMI for 6lowpan purposes does not seem the appropriate thing to do - this WG or other organizations involved with this technology would not have the expertise to do it, and doing it may not result in the desired effects.

I would suggest to re-write these paragraphs so that they include a more clear definition of the operational modes and requirements for management in 6lowpan deployments, what are the resources that need to be controlled on the devices and in the protocol (message size for example) and from here to derive requirements for the protocols to be used without specifying any protocol at this phase. Selection of the protocol or protocols that can meet the manageability and operational requirements for 6lowpan should make the object of later work.

[Ballot discuss]
The document says:

  3.  An admittedly non-technical but important consideration is that
      intellectual property conditions for IP networking technology are
      either more favorable or at least better understood than
      proprietary and newer solutions.

Wouldn't publication of this as-is imply that the IETF as a whole had
surveyed the IPR landscape for this and come to this conclusion?  My
memory is that our lawyers don't like it when we say things like this....

PROTO Write-up

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

Yes. Geoff Mulligan will be the Document Shepherd for the document.

(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

Yes. The document has had a significant review by the working group
and by the Document Shepherd and we have reached consensus on the
document and there are no concerns about the extent of the reviews.

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML?

No. The document does not need further review from other areas.

(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here.

No. The Document Shepherd does not have any concerns about this
document.
All concerns were raised on the mailing list and have been dealt with.

(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

We have reached very strong broad consensus on this document. There
have been no dissenting opinions raised during the last review or during
the WGLC.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

No. No appeals have been threatened or raised.

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See
http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/). Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type and URI type reviews?

Yes. I ran the document through idnits and we corrected the problems
identified. There is one unnecessary Normative reference that was not
caught by idnits, but I have flagged the draft editor and it will be
corrected with any changes requested by the AD or IESG.

(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

Yes and all normative references in the document are to either
existing RFCs or to documents that are in the final stages of
standardization, i.e. already in IESG approval or are in the RFC
editor's queue.

(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggested a
reasonable name for the new registry? See
[I-D.narten-iana-considerations-rfc2434bis]. If the document
describes an Expert Review process has Shepherd conferred with
the Responsible Area Director so that the IESG can appoint the
needed Expert during the IESG Evaluation?

Yes the document has an IANA consideration section, but the document
contains no IANA issues and states this in the section.

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

There are no sections of the document that use a formal language.

(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Writeup? Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary
6LoWPAN is specification describing how to utilize
IPv6 on top of low power, low data rate, low cost personal area
networks. These networks today being built using IEEE 802.15.4
standard radios. These radios have an extremely limited frame
size which makes it necessary to define an adaptation layer to
support link layer fragmentation and reassembly. Additionally
since these networks utilize low power transmission it is
necessary for the adaptation layer to support network layer mesh
capabilities. This specification defines the header format for
this adaptation layer.

Working Group Summary
The working group reached consensus on this document.

Document Quality
There are at least 6 independent implementations of this protocol
being worked on and all concerns raised during the review and
WGLC have been addressed.

Personnel
Geoff Mulligan is the Document Shepherd.
Mark Townsley is the responsible Area Director.