Randy Bush writes: http://www.piuha.net/~jarkko/publications/mipv6/issues/issue284.txt and further From: Greg O'Shea I have been raising issues on the MobileIP list as I encounter them, resulting in a number of mods to the spec of which my favourite was removal of the S bit in binding updates. Of what remains I do not know of anything that I think warrants delay. IMHO what is needed most at this point is a stake in the ground (an initial stable spec.) pending which everyone is sitting painfully still and holding their breath. Once the base spec is approved I expect the innovation and serious experimentation will begin afresh around it. I do think that the specification could have been simpler, although this is not a show stopper and once the initial base spec is approved there may be efforts in this direction. I believe that home nets and therefore home addresses should be virtual nets e.g. on a virtual IF on a HA. This means that random hosts cannot directly attach to the net and interfere with address assignment. In turn this means that HA need not run DAD before protecting a HoA, the HA need not protect link-local addresses derived from HoA, NS code is simpler and in some cases handoff latency is reduced by a second or two. This idea was well received on the list but has been set aside as future work. I am somewhat dubious about the HA discovery and prefix discovery stuff. At best I think it belongs in a separate doc. It doesn't achieve much at all with manual keying. But again that is not a show stopper. ------------------- Jari Arkko responds to Randy Bush: I checked the I-D tracker and found some comments from you on draft-ietf-mobileip-mipv6-ha-ipsec-04.txt. Thank you for the comments! Its somewhat unclear to me whether I should e-mail discussion about the matter to you directly or via Thomas. Anyway, here's some initial responses: > http://www.piuha.net/~jarkko/publications/mipv6/issues/issue284.txt Yes, these are the comments that Bernard Aboba raised. My understanding is that we reached an agreement about the modifications. A "prerelease" of the draft version 05 is available at http://www.piuha.net/~jarkko/publications/mipv6/drafts/mipv6haipsec.txt http://www.piuha.net/~jarkko/publications/mipv6/drafts/mipv6haipsec.html http://www.piuha.net/~jarkko/publications/mipv6/drafts/mipv6haipsecdiff.html > From: Greg O'Shea > I have been raising issues on the MobileIP list as I encounter them, > resulting in a number of mods to the spec of which my favourite was > removal of the S bit in binding updates. Of what remains I do not know > of anything that I think warrants delay. > > IMHO what is needed most at this point is a stake in the ground (an > initial stable spec.) pending which everyone is sitting painfully > still and holding their breath. Once the base spec is approved I > expect the innovation and serious experimentation will begin afresh > around it. Yes, most people feel this way. One particular area where there are a lot of interested folks is optimizations, such as reducing the time to do IPv6 link-up signaling and movement-related MIPv6 signaling. > I do think that the specification could have been simpler, although > this is not a show stopper and once the initial base spec is > approved there may be efforts in this direction. I believe that home Indeed. Everyone agrees with this, I think -- including me and Charlie. (I do think Greg refers mainly to the base specification,) Anyway, most people also feel that we should publish the specification now and not start debating how to split it; Thomas is also planning to charter a MIPv6 working group with the task of updating to DS. This update would consist of the usual DS tasks, as well as leave time for us to do an editorial split of the document, maybe prefix and home agent discovery in their own documents etc. > nets and therefore home addresses should be virtual nets e.g. on a > virtual IF on a HA. This means that random hosts cannot directly > attach to the net and interfere with address assignment. In turn this > means that HA need not run DAD before protecting a HoA, the HA need > not protect link-local addresses derived from HoA, NS code is simpler > and in some cases handoff latency is reduced by a second or two. This > idea was well received on the list but has been set aside as future > work. Thats right. My understanding is that some products are going to be based on virtual networks. The advantage is that both home agents and mobile nodes need to do less, can do it more efficiently since there's no need to wait for others to respond to DAD, etc. One drawback of the virtual network approach is that if its the only one offered, then you'd have to do tunneling to home (or route optimization signaling) even if you are at home. The WG would probably have gone for this approach if it weren't for this problem. In any case, one of the ideas for a DS/revised MIPv6 RFC is that we could define a class of home agents with only virtual home networks. The requirements for such home agents would be smaller than for full-fledged home agents. > I am somewhat dubious about the HA discovery and prefix discovery > stuff. At best I think it belongs in a separate doc. It doesn't > achieve much at all with manual keying. But again that is not a show > stopper. Right. I don't disagree with Greg on this. There's been WG debate about these things, and our consensus was to keep them in the main specification regardless of the fact that they are not as useful as one might imagine, given that you also need to set up security. We could perhaps revisit that decision if the IESG so wishes. My personal feeling is that it would be most useful to separate these features later and keep them in the spec for now. Conclusion: The specific issues raised by Bernard have been corrected. Greg's earlier issues on the mailing list have also been corrected, such as the removal of the S bit, which simplified the specification quite a bit. The rest... I need guidance on how you at IESG want us to proceed on them. The WG has debated these issues in the past, and what's in the document is the current consensus. It is true that it would have been better if this specification (and some other IETF specifications) would have been started off as more modular. But at least we have a plan on how to move into that direction ------------------- Charlie Perkins writes: After reading this issue several times, I didn't see that there was any action point suggested. Is it possible to close the issue? ------------------- Jari Arkko responds to Charlie Perkins: I think so, but I'd like to get Randy's answer back first... basically the issue consisted of problems Bernard Aboba had and which we had already fixed earlier, and Greg's split vs. not split and virtual home nets vs. not discussions that we've had in the WG earlier and where we have already made the decisions. I have put the issue tentatively at "Rejected?" status, pending answer. ------------------- Randy Bush responds to Jari Arkko: > Conclusion: The specific issues raised by Bernard have been > corrected. bernard, to your satisfaction? > Greg's earlier issues on the mailing list have also been > corrected, such as the removal of the S bit, which simplified the > specification quite a bit. he seems to feel that his issues were addressed to his satisfaction. > The rest... I need guidance on how you at IESG want us to proceed > on them. The WG has debated these issues in the past, and what's > in the document is the current consensus. It is true that it > would have been better if this specification (and some other IETF > specifications) would have been started off as more modular. But > at least we have a plan on how to move into that direction the time to make a simpler spec is in the begining. now would be a restart. so, pending bernard's comment, i am cool with this. ------------------- Bernard Aboba responds to Randy Bush: > bernard, to your satisfaction? Yes, pending a look at -05. ------------------- ------------------- -------------------