Problem Statement and Requirements for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing
RFC 6606

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

Lars Eggert No Objection

Comment (2010-05-20 for -)
No email
send info
I have a few questions:

Section 4., paragraph 15:
>        *  Classes of Service:
>           For mixing applications of different criticality on one
>           LoWPAN, support of multiple classes of service may be required
>           in resource-constrained LoWPANs and may require a certain
>           degree of routing protocol overhead.

  I'm not sure I see why. QoS support typically involves end-to-end
  transport functions and more complex *queueing*, but not routing
  *protocol* overheads. Could you explain?


Section 4., paragraph 17:
>    b.  Node Parameters:

  Isn't queuing strategy and queue buffer size also a parameter?


Section 4., paragraph 21:
>        *  Traffic Pattern:
>           This parameter affects routing since highly loaded nodes
>           (either because they are the source of packets to be
>           transmitted or due to forwarding) may contribute to higher
>           delivery delays and may consume more energy than lightly
>           loaded nodes.  This applies to both data packets and routing
>           control messages.

  Again, I'm not sure I understand. Why does the volume of application
  data sent or received by some nodes affect the routing *protocol*?

(Ralph Droms; former steering group member) Yes

Yes ( for -)
No email
send info

(Adrian Farrel; former steering group member) (was Discuss) No Objection

No Objection (2010-09-29)
No email
send info
I remain unhappy about the objective of this document within the IETF since it seems to be capturing requirements for routing in a 6lowpan that form a subset of the requirements already documented and addressed by the ROLL working group. Nevertheless, since my gripes are mainly about process, I am taking them out of my Discuss so that the document can proceed. I would still be happy to have it clarified to me how this document fits in with the ROLL effort.

(Dan Romascanu; former steering group member) (was Discuss) No Objection

No Objection ()
No email
send info

(Gonzalo Camarillo; former steering group member) No Objection

No Objection ( for -)
No email
send info

(Jari Arkko; former steering group member) No Objection

No Objection ( for -)
No email
send info

(Ron Bonica; former steering group member) No Objection

No Objection ( for -)
No email
send info

(Russ Housley; former steering group member) No Objection

No Objection ( for -)
No email
send info

(Sean Turner; former steering group member) (was Discuss, No Objection) No Objection

No Objection (2010-05-18)
No email
send info

(Stewart Bryant; former steering group member) (was Discuss) No Objection

No Objection ()
No email
send info

(Tim Polk; former steering group member) (was Discuss) No Objection

No Objection (2010-05-20)
No email
send info
Is there an example of a power affluent node that is *not* mains-powered?  And does this have
any impact on the routing requirements?