Skip to main content

Design and Application Spaces for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)



(Adrian Farrel)
(Ralph Droms)

No Objection

(Dan Romascanu)
(David Harrington)
(Gonzalo Camarillo)
(Russ Housley)
(Sean Turner)

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

Lars Eggert Former IESG member
Discuss [Treat as non-blocking comment] (2011-03-01) Unknown
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. 
Adrian Farrel Former IESG member
(was Discuss) Yes
Yes () Unknown

Ralph Droms Former IESG member
Yes () Unknown

Dan Romascanu Former IESG member
No Objection
No Objection () Unknown

David Harrington Former IESG member
No Objection
No Objection () Unknown

Gonzalo Camarillo Former IESG member
No Objection
No Objection () Unknown

Jari Arkko Former IESG member
No Objection
No Objection (2011-03-03) Unknown
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. 


Figure 4: "I" in the legend is redundant (there's no "I" in the figure)
Peter Saint-Andre Former IESG member
No Objection
No Objection (2011-03-01) Unknown
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.
Robert Sparks Former IESG member
No Objection
No Objection (2011-03-02) Unknown
Consider clarifying whether the set of dimensions here is intended as a complete list, or is just an important set currently identified.
Russ Housley Former IESG member
No Objection
No Objection () Unknown

Sean Turner Former IESG member
(was Discuss, No Objection) No Objection
No Objection (2011-12-19) Unknown

Stewart Bryant Former IESG member
No Objection
No Objection (2011-03-02) Unknown
An interesting and well written document.

I agree with Peter that RFC2119 language does not seem appropriate.

Tim Polk Former IESG member
(was Discuss) No Objection
No Objection (2011-03-02) Unknown
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.