Greg O'Shea writes: Let me mention, again, that *all* of this stuff about DAD and NS on home link and special handling for link-local special traffic on the home net, including the cases we haven't thought of yet, can be removed if you make the home nets virtual as per the original proposal of issue 198. (Sigh.) The idea of #198 was well-received but apparently rejected in the interests of expediency and to save disturbing the text of the existing spec. I do not find those very plausible arguments for imposing unnecessary complexity upon implementors and operators of the protocol. Instead the idea has been deferred to a future "MIPv6bis" working group whose job it will be, presumably, to sort out MIPv6 after the IESG have approved it. Some important questions arise: 1) What is are plan and the remit for this MIPv6bis working group? 2) If we plan to rehash the current spec then why are we asking the IESG to approve something inferior? 3) What will be the status of the current spec if the IESG approve it. Can implementors depend upon it? 4) Could the IESG are wasting its time on the current spec or could the MIPv6bis WG will be wasting its time after the horse has bolted? ------------------- Ed Remmell responds to Greg O'Shea: From my perspective, we are pretty close already with the current draft to having a workable MN specification. IMHO, I see no reason to do major rework or to pull this specification off of the IETF track. Just IMHO. ------------------- Greg O'Shea responds to Ed Remmell: Actually I pretty much agree with that. But I think we should do MIPv6 well, once, now. I do not think a weak spec to be rehashed in a new WG is anything other than a diversion, prossibly a loop. The scope of the current draft has expanded too much making it large, hard to manage and near impossible to stablize. In a sense this is a structural issue with the spec itself. I believe progress would be (would have been, still could be) faster and easier if it were broken into at least three parts: 1) minimalist essential core - no real home nets hence no DAD or L or NS hacks and minimum of anything else controversial 2) support for real home nets - optional with DAD,L,NS etc 3) DHAAD and prefix discovery It is good that much of the IPSec is already separate. ------------------- Jari Arkko responds to Greg O'Shea: > 1) What is are plan and the remit for this MIPv6bis working group? > 2) If we plan to rehash the current spec then why are we asking the IESG > to approve something inferior? This is a normal part of the IETF specification development. Standards get first to the Proposed Standard status, and then they are later upgraded to Draft Standard if there's sufficient interoperability and other experience. As a part of the upgrade (or other recycle) they can be edited, features not implemented by at least two implementations get removed, errors may be fixed, etc. I'd expect there to be significant input from experience to the specification, including: - Tuning of the constants - Error and other cases missed from the specification - Practical deployment experience of ha-mn security and key management - Effects based on other developments e.g. optimistic DAD - Experiences on dhaad and prefix discovery - Etc. One possible idea for an editorial change is that at the time the bis RFC is being made, we should also split the document into smaller pieces. Not rewrite the whole thing, but e.g. remove an unused function, or put ha/mn/cn into different documents, or split according to your suggestion of virtual/real home networks. > 3) What will be the status of the current spec if the IESG approve it. > Can implementors depend upon it? Its a Proposed Standard. It will never disappear as an RFC, if that's what you are asking. A DS version may appear with some features removed as explained above, but hopefully its backwards compatible. An editorial split should not affect the implementor's ability to depend on the document. Only technical modifications will affect it; but would you object in year N+1 if we made real-world home links optional? > 4) Could the IESG are wasting its time on the current spec or could the > MIPv6bis WG will be wasting its time after the horse has bolted? No, I think whatever we do we are bound to release a bis RFC sometime after the first RFC comes out, particularly if it provides significant new functionality and will be widely deployed. We could of course try and split the document right now as well. But I'm not sure how beneficial it would be just as an editorial exercise -- might be better combined with some deployment experience which at the same time would allow us other edits. Greg, you are right of course about the hard work we need to get the spec stable and close all issues. But again, this alone will not close all issues, I think we should focus on the technical changes we should do or not do now. So, the only question that we should have is whether we now have something in the spec that we indeed consider wrong -- but we've debated the issue of the virtual home nets vs. keeping the on-link-home functionality in the spec. And it seemed to me that the WG reached an opinion on that although obviously not everyone agreed. This happens sometimes, though. ------------------- I see we're discussing how to partition the existing spec into smaller parts. This is mostly out of scope for now. We are going to publish this spec as close to rev20 as we can, because that is the consensus that has brought us this far. And there's much more consensus there than in any proposed subdivision of the protocol right now. Any discussions on how to break it out are great and let's keep note of them, but they are really only relevant after we publish this document and get some more experience with the protocol. Also, the fact that anybody publishes an RFC does not mean it won't change. After all, it's initially a *Proposed* standard. Changes are expected to happen as it progresses from Proposed to Draft and then to Internet Standard. We are not making an exception. We're just merely being proactive on the usual and expected IETF process, see section 4.1 in: http://www.ietf.org/rfc/rfc2026.txt And by the way, not only is it possible to change a protocol, it is also possible to retract it (as per the above published process). This isually doesn't happen. Changes in a document,however, do happen and are expected. Let's please concentrate on the task at hand of closing the remaining issues. ------------------- Greg O'Shea responds to Jari Arkko: Okay, thanks, I still tend to think that all RFC are equal. I'll come quietly. ------------------- ------------------- -------------------