A side note on this draft. First - please don't overeact, I know, I
should discuss this on tlp-interest - ok, I will.
I wanted to publicly let the group know that I don't agree with the
conditions in the preamble (boilerplate) of this draft.
In the past I may have commented technically on this draft.
Right now I must say I don't agree with its licensing.
That's all, thanks for ignoring this message. I just want it to be here
if any use for later.
Yours,
Alex
(I am trying to do the same about all drafts I've been commented on
recently because I just discovered the new IETF Trust licensing
scheme in the boilerplate.)
Le 01/02/2010 23:17, Zach Shelby a écrit :
Hi everyone,
Thanks to an active discussion among the ND authors, and a bunch of
helpful reviews (thanks Richard, Anders and Colin), I finally managed
to post 6lowpan-nd-08, in its new slim form (think biggest loser).
After Hiroshima we reached good WG consensus to split the ND work
into the basic mechanism (which is now this document) and a separate
Extended LoWPAN draft (to be started), furthermore we agreed to deal
with the DAD issue. This document hopefully moves us very close to
that goal. This also includes the new RS feature suggested by
Anders.
http://www.ietf.org/id/draft-ietf-6lowpan-nd-08.txt
As always with major changes (this needed lots of hacking and major
editing), there are surely tons of bugs and loose-ends left. Help to
find those appreciated.
Changes from -07 to -08:
o Removed Extended LoWPAN and Whiteboard related sections.
o Included reference to the autoconf addressing model.
o Added Optimistic Flag to 6AO.
o Added guidelines on routers performing DAD.
o Removed the NR/NC Advertising Interval.
o Added assumption of uniform IID formation and DAD throughout a
LoWPAN.
The major open issue we have is how to develop the DAD text in
Section 5.3 in such a way that it works for most people, yet produces
reliable and safe LoWPANs, and is yet acceptable to the IPv6 crowd
and especially the IESG ;-) We are trying to find a balance to keep
the WG happy, yet having a chance to actually become an RFC....
It would also be nice to reduce the complexity of NR/NC and
especially 6AO message processing. Writing the spec, I am at least
not totally happy with the amount of explaining needed.... Is there a
sleeker way to deal with the addresses?
Zach
Begin forwarded message:
From: IETF I-D Submission Tool<[email protected]> Date:
February 1, 2010 23:59:40 GMT+02:00 To: [email protected] Cc:
[email protected],[email protected],[email protected],[email protected],[email protected]
Subject: New Version Notification for draft-ietf-6lowpan-nd-08
A new version of I-D, draft-ietf-6lowpan-nd-08.txt has been
successfuly submitted by Zach Shelby and posted to the IETF
repository.
Filename: draft-ietf-6lowpan-nd Revision: 08 Title:
6LoWPAN
Neighbor Discovery Creation_date: 2010-02-01 WG ID: 6lowpan
Number_of_pages: 46
Abstract: This document specifies a new Neighbor Discovery
mechanism suitable for LoWPANs. The 6LoWPAN format allows IPv6 to
be used over energy and bandwidth constrained wireless networks
often making use of multihop topologies. However, the use of
classic IPv6 Neighbor Discovery with 6LoWPAN has several problems.
Classic Neighbor Discovery was not designed for non-transitive
wireless links, and the traditional IPv6 link concept and heavy use
of multicast makes it unpractical. This document specifies a
simple Neighbor Discovery mechanism both sufficient yet minimal for
LoWPAN operation.
The IETF Secretariat.
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
