So to wrap this up - and let everyone relax over the weekend - let me
summarize here. Considering the route-over, non-transitive,
sleeping-node environment we are working with - 6LoWPAN-ND has solved
the problem quite nicely. Now we're really talking about how to explain
it in a realistic way, minimize the downsides, and work out the bugs.
So I propose the following tickets:
1. Remove stateless from the draft, except in reference to the use of
RFC4682 SAA while forming addresses (it is the name of the RFC...).
2. We attempt explain the whiteboard in a realistic context in the
draft, not claiming it walks on water or anything.
3. Improve the address and OII collision text, and the coverage of
cases. Pascal and Carsten will work on that, suggestions welcome.
Separate thread.
4. Clarify that other methods can be used to form addresses, not only
SAA. For example manual configuration, DHCP or any other method (e.g.
link-layer assignment).
5. Ticket to improve the Ad-hoc LoWPAN case, based on Richard's feedback
on large ad-hoc networks. Things to consider include making the
whiteboard optional for that case, or somehow minimizing the state
needed in an ER. Separate thread.
Thanks everyone for the discussion, let's continue discussing 3 and 5
and work on constructive improvements.
- Zach
--
http://www.sensinode.com
http://zachshelby.org - My blog “On the Internet of Things”
Mobile: +358 40 7796297
Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND
This e-mail and all attached material are confidential and may contain
legally privileged information. If you are not the intended recipient,
please contact the sender and delete the e-mail from your system without
producing, distributing or retaining copies thereof.
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
