Hi Jari, As per your request below, we broke up the original I-D into separate drafts. We decided to make three drafts rather than the two you suggested so that the third can be incorporated into any new ND documents at some future time when such changes are allowed.
The URLs to the new drafts follow: 1) http://www.ietf.org/internet-drafts/draft-wbeebee-on-link-and-off-link-d etermination-00.txt 2) http://www.ietf.org/internet-drafts/draft-wbeebee-nd-implementation-prob lems-00.txt 3) http://www.ietf.org/internet-drafts/draft-wbeebee-nd-updates-00.txt Please review the drafts in the order of precedence listed (reviewing #3 quickly is of lesser importance than reviewing #1 and #2). Note that #1 and #3 are on the standards track, whereas #2 is informational. Thanks. Hemant & Wes. -----Original Message----- From: Jari Arkko [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 21, 2007 7:03 AM To: Hemant Singh (shemant) Cc: Hesham Soliman; Wes Beebee (wbeebee); Thomas Narten; IETF IPv6 Mailing List Subject: On-link issues, draft-wbeebee, 2461bis Hemant, I have reviewed your draft and the discussion on the IPv6 list. Its easy to believe that there are implementations out there that get things wrong. I also agree with the general technical direction about DAd and being specific about where ND on-link assumptions and prefixes can come from. And we should value implementation experience and document it where it can potentially help future implementers. However, we already had a discussion about whether the 2462bis document should change. The WG believes they have gotten the current requirements right, and I can't really blame them for that. Please note that once 2462bis is an RFC, IETF's official recommendation is to do exactly what you want to happen. Those implementations that pay attention to such things will change (if they need to). It is unfortunate that earlier RFCs and some implementations operated differently. But it is something that issuing a new RFC cannot alone fix; we just have to live with that. I would also note that the DAD process as a whole is not bullet proof. Dropped packets, network partition, etc. can still cause duplicated addresses to occur. The engineering is to get the probability of that happening reasonably low, and I think we are there. You also suggested that 2461bis be changed to clarify the on/off-link rules. I thought that most of your clarified rules were good, though I did not perform a detailed review so there may still be issues. I note that others had question marks on some of them. In any case, my big question is to what extent you are (a) making an implementation error less likely by emphasizing and reformulating rules that 2461bis already has or (b) making some actual new, tighter rules. I think most of it falls under category (a). Is there some that are in (b)? However, the amount of new text goes beyond what we can put in under AUTH48. Given that the group does not seem to unanimously believe that the rules are missing from 2461bis, I feel reluctant to go through the approval process once more. It is more important to have a standard than to achieve perfection. However, I would like to make sure that the implementation guidance is not lost. And it may even be that after a discussion we realize that the on-link rules need further work. Its completely possible that we have to clarify some part of ND even after 2461bis has been published; the maintenance WG has been created in order to deal with issues like that. Here's what I would suggest: 1) We proceed with 2461bis publication. 2) We proceed with 2462bis publication. 3) You write one document that collects the implementation guidance/clarified rules regarding on/off link behaviour, and offer it for the new IPv6 maintenance WG. 4) You write another document that collects other implementation experience, and also offer it to the same WG. Jari -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
