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

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

(Lars Eggert) Discuss

Discuss (2011-03-01 for -)
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. 

(Ralph Droms) Yes

(Adrian Farrel) (was Discuss) Yes

(Jari Arkko) No Objection

Comment (2011-03-03 for -)
No email
send info
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)

(Stewart Bryant) No Objection

Comment (2011-03-02 for -)
No email
send info
An interesting and well written document.

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

(Gonzalo Camarillo) No Objection

(David Harrington) No Objection

(Russ Housley) No Objection

(Tim Polk) (was Discuss) No Objection

Comment (2011-03-02)
No email
send info
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.

(Dan Romascanu) No Objection

(Peter Saint-Andre) No Objection

Comment (2011-03-01 for -)
No email
send info
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) No Objection

Comment (2011-03-02 for -)
No email
send info
Consider clarifying whether the set of dimensions here is intended as a complete list, or is just an important set currently identified.

(Sean Turner) (was Discuss, No Objection) No Objection