Skip to main content

Design and Application Spaces for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)
draft-ietf-6lowpan-usecases-10

Revision differences

Document history

Date Rev. By Action
2012-08-22
10 (System) post-migration administrative database adjustment to the No Objection position for Sean Turner
2012-08-22
10 (System) post-migration administrative database adjustment to the No Objection position for Tim Polk
2012-08-22
10 (System) post-migration administrative database adjustment to the Yes position for Adrian Farrel
2012-01-26
10 (System) IANA Action state changed to No IC
2012-01-25
10 Amy Vezza State changed to RFC Ed Queue from Approved-announcement sent.
2012-01-24
10 Amy Vezza IESG state changed to Approved-announcement sent
2012-01-24
10 Amy Vezza IESG has approved the document
2012-01-24
10 Amy Vezza Closed "Approve" ballot
2012-01-24
10 Amy Vezza Approval announcement text regenerated
2012-01-24
10 Amy Vezza Ballot writeup text changed
2012-01-24
10 Amy Vezza State changed to Approved-announcement to be sent from IESG Evaluation::AD Followup.
2011-12-19
10 Sean Turner [Ballot Position Update] Position for Sean Turner has been changed to No Objection from Discuss
2011-12-19
10 Ralph Droms Ballot writeup text changed
2011-08-10
10 Adrian Farrel [Ballot comment]
Thank you for addressing my Discuss with some more substantive Security text both in the Security Considertions section and splattered through the document.
2011-08-10
10 Adrian Farrel [Ballot Position Update] Position for Adrian Farrel has been changed to Yes from Discuss
2011-07-26
10 (System) Sub state has been changed to AD Follow up from New Id Needed
2011-07-26
10 (System) New version available: draft-ietf-6lowpan-usecases-10.txt
2011-03-26
10 Tim Polk [Ballot Position Update] Position for Tim Polk has been changed to No Objection from Discuss
2011-03-26
10 Sean Turner
[Ballot comment]
In 3.5.1, the telematics example has a deployment parameter of "scattered, pre-
planned".  Somehow these seem in conflict.

I share Lars' concern about …
[Ballot comment]
In 3.5.1, the telematics example has a deployment parameter of "scattered, pre-
planned".  Somehow these seem in conflict.

I share Lars' concern about QoS requirements.
2011-03-26
10 Sean Turner
[Ballot discuss]
I'm picking up Tim's discuss position.

The Security Considerations overlooks a number of very important
issues/challenges raised by the use cases.

First, a …
[Ballot discuss]
I'm picking up Tim's discuss position.

The Security Considerations overlooks a number of very important
issues/challenges raised by the use cases.

First, a number of the use cases are vulnerable to physical threats, including
device theft and simple vandalism.  Given the safety issues involved in some use
cases, this would seem to place specific demands for resiliency and
survivability upon the 6lowpan.  This issue seems to be overlooked entirely.

Second, while the existing security considerations briefly touch on the need for
encryption, the treatment does not expose the real issues at play.  There is a
reference to "lightweight key mechanisms" that deserves expansion - what are
those mechanisms (references please!)  The discussion of encryption overlooks a
fundamental problem - the slow processors and limited memory capacity described
in section 1 will be challenged by generally accepted cryptographic algorithms.
However, the safety concerns associated with many use cases precludes deployment
of weak cryptography!

I suspect that authentication will provide a similar set of challenges.
Configuration of strong authentication, with role-based access controls, on the
nodes of even a medium sized lowpan seems problematic.  (I don't recall the
specific deployment challenge of provisioning/configuring the security controls
being addressed in the body of the document.)
2011-03-26
10 Sean Turner [Ballot Position Update] Position for Sean Turner has been changed to Discuss from No Objection
2011-03-03
10 Samuel Weiler Request for Last Call review by SECDIR Completed. Reviewer: Donald Eastlake.
2011-03-03
10 Cindy Morgan Removed from agenda for telechat
2011-03-03
10 Cindy Morgan State changed to IESG Evaluation::Revised ID Needed from IESG Evaluation.
2011-03-03
10 David Harrington [Ballot Position Update] New position, No Objection, has been recorded
2011-03-03
10 Dan Romascanu [Ballot Position Update] New position, No Objection, has been recorded
2011-03-03
10 Jari Arkko
[Ballot comment]
Some comments from Ari Keränen:

One question/comment:

3.6.2.  6LoWPAN Applicability

  Communication schedules must be set up between
  master and leaf nodes, …
[Ballot comment]
Some comments from Ari Keränen:

One question/comment:

3.6.2.  6LoWPAN Applicability

  Communication schedules must be set up between
  master and leaf nodes, and global time synchronization is needed to
  account for clock drift.

Wouldn't time synchronization within the LoWPAN (i.e., not globally) be enough for this use case?


And some nits:

3.2.1.  A Use Case and its Requirements

The second sentence of this paragraph is a bit hard to parse:

  The physical network topology is changed in case of node failure.  On
  the top part of each pillar, an sink node is placed to collect the
  sensed data.  The sink nodes of each pillar become data gathering
  point of the LoWPAN hosts at the pillar as local coordinators.

Perhaps add something like "and act" before the "as the [...]" part (if that's what it means)?
Also: s/an sink/a sink/


3.3.2.  6LoWPAN Applicability

  In home network, installation and management must as extremely simple
  for the user.

s/as/be/


Figure 4: "I" in the legend is redundant (there's no "I" in the figure)
2011-03-03
10 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded
2011-03-03
10 Gonzalo Camarillo [Ballot Position Update] New position, No Objection, has been recorded
2011-03-03
10 Sean Turner [Ballot comment]
I support Tim's discussion.
2011-03-03
10 Sean Turner [Ballot Position Update] New position, No Objection, has been recorded
2011-03-02
10 Tim Polk
[Ballot comment]
In 3.5.1, the telematics example has a deployment parameter of "scattered, pre-planned".  Somehow these seem in conflict.

I share Lars' concern about QoS …
[Ballot comment]
In 3.5.1, the telematics example has a deployment parameter of "scattered, pre-planned".  Somehow these seem in conflict.

I share Lars' concern about QoS requirements.
2011-03-02
10 Tim Polk [Ballot comment]
In 3.5.1, the telematics example has a deployment parameter of "scattered, pre-planned".  Somehow these seem in conflict.
2011-03-02
10 Tim Polk
[Ballot discuss]
The Security Considerations overlooks a number of very important issues/challenges raised by the use cases.

First, a number of the use cases are …
[Ballot discuss]
The Security Considerations overlooks a number of very important issues/challenges raised by the use cases.

First, a number of the use cases are vulnerable to physical threats, including device theft and simple vandalism.  Given the safety issues involved in some use cases, this would seem to place specific demands for resiliency and survivability upon the 6lowpan.  This issue seems to be overlooked entirely.

Second, while the existing security considerations briefly touch on the need for encryption, the treatment does not expose the real issues at play.  There is a reference to "lightweight key mechanisms" that deserves expansion - what are those mechanisms (references please!)  The discussion of encryption overlooks a fundamental problem - the slow processors and limited memory capacity described in section 1 will be challenged by generally accepted cryptographic algorithms.  However, the safety concerns associated with many use cases precludes deployment of weak cryptography!

I suspect that authentication will provide a similar set of challenges.  Configuration of strong authentication, with role-based access controls, on the nodes of even a medium sized lowpan seems problematic.  (I don't recall the specific deployment challenge of provisioning/configuring the security controls being addressed in the body of the document.)
2011-03-02
10 Tim Polk [Ballot Position Update] New position, Discuss, has been recorded
2011-03-02
10 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded
2011-03-02
10 Adrian Farrel
[Ballot discuss]
A splendid and useful document that is let down by the Security
Considerations section.

The applicability of 6LowPANs is significantly dependent on suitable …
[Ballot discuss]
A splendid and useful document that is let down by the Security
Considerations section.

The applicability of 6LowPANs is significantly dependent on suitable
security mechanisms being available. Since 6LowPANs are very vulnerable
to physical layer attacks, it is important to discuss the options and
to identify when the use of these networks is not advisable.

If you can add some beef to that section, I would happily change my
ballot to Yes.
2011-03-02
10 Adrian Farrel [Ballot Position Update] New position, Discuss, has been recorded
2011-03-02
10 Robert Sparks [Ballot comment]
Consider clarifying whether the set of dimensions here is intended as a complete list, or is just an important set currently identified.
2011-03-02
10 Robert Sparks [Ballot Position Update] New position, No Objection, has been recorded
2011-03-02
10 Stewart Bryant [Ballot comment]
An interesting and well written document.

I agree with Peter that RFC2119 language does not seem appropriate.
2011-03-02
10 Stewart Bryant [Ballot Position Update] New position, No Objection, has been recorded
2011-03-01
10 Peter Saint-Andre
[Ballot comment]
This is a pleasant document. However, given that it discusses use cases and deployment scenarios, I doubt that it needs to use RFC …
[Ballot comment]
This is a pleasant document. However, given that it discusses use cases and deployment scenarios, I doubt that it needs to use RFC 2119 conformance terms at all. For example, consider the following sentence from Section 3.2: "Some data is not critical for security protection (such as normal room temperature), but event-driven emergency data (such as a fire alarm) MUST be handled in a very critical manner." Well, that's probably the case, but it's really a matter of local service policy, isn't it? Similarly, the assertion in Section 3.4.1 that "Data privacy and security MUST be provided" in healthcare systems is really a matter of either local service policy or applicable legislation (e.g., HIPAA), not RFC 2119 conformance.
2011-03-01
10 Peter Saint-Andre [Ballot Position Update] New position, No Objection, has been recorded
2011-03-01
10 Ralph Droms State changed to IESG Evaluation from Waiting for AD Go-Ahead.
2011-03-01
10 Lars Eggert
[Ballot discuss]
I have a pretty fundamental issue with this document. Many of the described use cases make requirements on the 6lowpan architecture that I …
[Ballot discuss]
I have a pretty fundamental issue with this document. Many of the described use cases make requirements on the 6lowpan architecture that I don't think are realistic, or at least it's very unclear how and if they can be achieved. The key example is the "support for QoS" requirement that is said to be very important for many use cases, yet I see no mechanisms in the actual 6lowpan specs that would support different levels of QoS, or even any text that would define what "support for QoS" even means in low-powered, maybe-disconnected networks. Surely it cannot only mean priority queuing, because that's clearly not sufficient for many of the described uses. Another requirement that is similarly problematic is "reliable delivery" (which is for some reason included under security). It's not clear at all to me whether reliable delivery can be achieved with any sort of timing constraints.

I'm not quite sure how I can make this discuss actionable.
2011-03-01
10 Lars Eggert [Ballot Position Update] New position, Discuss, has been recorded
2011-03-01
10 (System) State changed to Waiting for AD Go-Ahead from In Last Call.
2011-02-28
10 Amanda Baber We understand that this document does not require any IANA actions.
2011-02-24
10 David Harrington Request for Last Call review by TSVDIR is assigned to Nandita Dukkipati
2011-02-24
10 David Harrington Request for Last Call review by TSVDIR is assigned to Nandita Dukkipati
2011-02-16
10 Ralph Droms [Ballot Position Update] New position, Yes, has been recorded for Ralph Droms
2011-02-16
10 Ralph Droms Ballot has been issued
2011-02-16
10 Ralph Droms Created "Approve" ballot
2011-02-16
10 Samuel Weiler Request for Last Call review by SECDIR is assigned to Donald Eastlake
2011-02-16
10 Samuel Weiler Request for Last Call review by SECDIR is assigned to Donald Eastlake
2011-02-15
10 Amy Vezza Last call sent
2011-02-15
10 Amy Vezza
State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC: < …
State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC: <6lowpan@lists.ietf.org>
Reply-To: ietf@ietf.org
Subject: Last Call:  (Design and Application Spaces for 6LoWPANs) to Informational RFC


The IESG has received a request from the IPv6 over Low power WPAN WG
(6lowpan) to consider the following document:
- 'Design and Application Spaces for 6LoWPANs'
  as an Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-03-01. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-6lowpan-usecases/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-6lowpan-usecases/

2011-02-15
10 Ralph Droms Placed on agenda for telechat - 2011-03-03
2011-02-15
10 Ralph Droms Status Date has been changed to 2011-02-15 from None
2011-02-15
10 Ralph Droms Last Call was requested
2011-02-15
10 Ralph Droms State changed to Last Call Requested from AD Evaluation.
2011-02-15
10 Ralph Droms Last Call text changed
2011-02-15
10 (System) Ballot writeup text was added
2011-02-15
10 (System) Last call text was added
2011-02-15
10 (System) Ballot approval text was added
2011-01-18
09 (System) New version available: draft-ietf-6lowpan-usecases-09.txt
2011-01-13
10 Ralph Droms Ballot writeup text changed
2010-11-15
10 Ralph Droms State changed to AD Evaluation from Publication Requested.
2010-11-09
10 Cindy Morgan [Note]: 'Geoff Mulligan (geoff.ietf@mulligan.com)is the document shepherd.' added by Cindy Morgan
2010-11-09
10 Cindy Morgan
  (1.a) Who is the Document Shepherd for this document? Has the
        Document Shepherd personally reviewed this version of the
  …
  (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?

Geoff Mulligan is the document shepherd.  I have personally reviewed the
document and believe it is ready for publication as an Informational RFC.



  (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? 

The document has undergone a thorough review by the 6lowpan WG
and I don't have concerns about the breadth of review.



  (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?

I don't think the document needs broader review.



  (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. Has an IPR disclosure related to this document
        been filed? If so, please include a reference to the
        disclosure and summarize the WG discussion and conclusion on
        this issue.

I'm not uncomfortable with any part of this document and I don't
have any specific concerns.  There has been no IPR disclosures
related to this document.  We have actually done several WGLC's
and the WG has reached consensus on this document.



  (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? 

There is strong consensus within the 6lowpan WG to publish this document.



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

There appears to be no discontent with this document.



  (1.g) Has the Document Shepherd personally verified that the
        document satisfies all ID nits? (See the Internet-Drafts Checklist
        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?

Only a single nit about 1 line length - no issues.



  (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 the document has split normative and informative references.



  (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 suggest a
        reasonable name for the new registry? See [RFC5226]. 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?

The section exists.  There are no IANA actions.

  (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?

Not applicable



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

    Technical Summary

  This document investigates potential application scenarios and use
  cases for low-power wireless personal area networks (LoWPANs).  This
  document provides dimensions of design space for LoWPAN applications.

    Working Group Summary
        Was there anything in WG process that is worth noting? For
        example, was there controversy about particular points or
        were there decisions where the consensus was particularly
        rough?

This document completed WGLC.



    Document Quality

This document was well reviewed by the 6lowpan WG.
2010-11-09
10 Cindy Morgan Draft Added by Cindy Morgan in state Publication Requested
2010-11-09
08 (System) New version available: draft-ietf-6lowpan-usecases-08.txt
2010-11-08
07 (System) New version available: draft-ietf-6lowpan-usecases-07.txt
2010-07-28
06 (System) New version available: draft-ietf-6lowpan-usecases-06.txt
2010-05-13
10 (System) Document has expired
2009-11-09
05 (System) New version available: draft-ietf-6lowpan-usecases-05.txt
2009-10-01
04 (System) New version available: draft-ietf-6lowpan-usecases-04.txt
2009-07-09
03 (System) New version available: draft-ietf-6lowpan-usecases-03.txt
2009-03-09
02 (System) New version available: draft-ietf-6lowpan-usecases-02.txt
2008-11-03
01 (System) New version available: draft-ietf-6lowpan-usecases-01.txt
2008-10-17
00 (System) New version available: draft-ietf-6lowpan-usecases-00.txt