Thank you for your review.
>>>>> "Pekka" == Pekka Savola <pekkas@xxxxxxxxxx> writes:
Pekka> In S 11 on Packet Forwarding:
Pekka> 1. This specification only covers how a successor is
Pekka> selected from the DODAG Version that matches the
Pekka> RPLInstanceID marked in the IPv6 header of the packet being
Pekka> forwarded. [...]
Pekka> ... How is RPLInstanceID marked in the IPv6 header of the
Pekka> packet being forwarded? Are you modifying IPv6 packet
Pekka> forwarding and processing algorithms here (must look into the
Pekka> packets)? That would be a major change. (You're really
Pekka> referring to the hop-by-hop header processing here.)
So, this is a signficant but as yet unsolved problem.
No details of the RPL protocol itself depend upon how in, the end, the
packets are marked.
At the beginning, many of us thought that the FlowLabel was the right thing
to use. And it works very well as long as the RPL network does not
need to interact with other networks.
Applications that run on RPL nodes that need a non-default behaviour
need to be aware of what RPLinstanceID to pick (and this is a
provionsing issue), and thus it will in fact be the application setting
the flow label, not an intermediate node.
Pekka> It is a bit strange to see that S 17 on manageability does
Pekka> not mention security management, because one of the key
Pekka> problems there (as argued in the draft as well) is how do you
Pekka> manually configure and maintain shared keys on all these
Pekka> devices.
I agree that it is a concern --- most of the deployment scenarios (which
are in a series of RFCs published by the WG last fall) are installed by
a single contractor into a single
commercial-building/house/factor/power-transmission-system
They initialize all the devices in the test lab, and then deploy them.
I think this is because 90% of the participants in the group think that
link-layer security provided by Zigbee is going to solve all of their
problems. I am very skeptical about this.
--
] He who is tired of Weird Al is tired of life! | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[
] mcr@xxxxxxxxxxxxxxxxxxxxxx http://www.sandelman.ottawa.on.ca/ |device driver[
Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
then sign the petition.
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf