Jari, Wrt to this point you raised snipped in quotes below, please see our response:
"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)?" In the -02 version of our I-D, we are not making any new rule over what has not been already specified in 2461bis or 2462bis. This is subject to everyone agreeing with our interpretation of 2461bis. So yes, I believe our rules fall only under (a) above. As for question marks on any text in our I-D, so far only Jinmei and Vlad Yasevitch have reviewed our I-D. Vlad reviewed the complete -01 version of our I-D. We closed all issues in -01 with him in the -02 version - he can correct me if I am mistaken. Jinmei reviewed only the portion of our -00 and/or -01 I-D that proposed changes to 2462bis. We have also closed any question marks with him on his review - he wanted us to back off forcing older host implementations to change for skipping DAD - we did back off. As to the extent of our clarification, I don't think the IPv6 community or the RFC's were clear on how to specify off-link in RA. We found passing references to off-link behavior in one paragraph of a general section 3.1 in 2461bis - we mention this paragraph in section 2.1 of our I-D. Then we found one paragraph in section 6.3.4 of 2462bis where off-link behavior was implied. Since off-link has been specified by 2461bis as the opposite of on-link, we are saying even on-link is not clearly specified in some cases. Therefore, it's not just stricter language and reformatting of rules that is the output of our I-D. 2461bis does not have ANY clear rules to specify off-link - it's just text buried in some paragraph that one has to interpret as off-link behavior. I have gone into enough details in emails as to why specifying on- vs. off-link is key to ND because that affects whether a host performs address resolution or send traffic to default router. Incorrect host behavior leads to loosing network connectivity in an aggregation router network. As per your guideline, here is our plan moving forward for the two documents. We are basically breaking up our I-D into two new documents where none of the two new documents will include sections 5 and 6 from our existing I-D - these section relate to proposed changes to 2461bis and 2462bis respectively. 1. We will put together a document that collects the implementation guidance/clarified rules regarding on/off link behavior - this document will include sections 2-4 of our current I-D. This document makes sense to be on Standards Track or be a BCP. 2. We will put together a second document that collects other implementation experience. This document will follow a format as specified in section 7 of our I-D. This document makes sense to be on Informational track. Anyone is welcome to send us logs of key ND bugs to add to this document. Best Regards. Hemant -----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 --------------------------------------------------------------------
