kre, > Name one operational annoyance? That is one that my use of > /112 (or someone else's use of /126 or /127) inflicts upon you, > assuming that you're not the other end of the link (if you are, > it is your choice to participate, no-one is compelling you to > use > /64).
I will address this in a reply to jj later. > then it really starts to look as if the only reason for > not changing is stubbornness. About which you and I are renowned world-class contestants ;-) > Maybe I wasn't clear enough that the 'u' but is the worst > part of the draft. It (or the part of it which pretends > to be visible externally) is the thing which most needs > to be deleted. I don't just want it gone in order that the > 64 bit boundary can go, I want it gone because it is > unimplementable nonsense, which doesn't belong in the doc. I understand the point you are trying to make, but I fail to understand the urgency. Part of your procedural argument before was that the 'u' bit was not implemented and therefore should be deleted. I disagree with the phrasing; I would much rather say something like it is implemented but not used. Correct me if I'm wrong, but I think the point you are trying to make is "Let's remove this 'u' bit before someone finds a nasty/dirty use for it". Without a context, I would agree with you, but you can't ignore the bigger picture. Since you are one of the persons who understand the details of the mechanisms behind MHAP and the differences with GSE, I hope that you also understand clearly that there is currently nothing in what ipv6mh is doing that suggests this. That being said, the reason I don't see the urgency of removing the 'u' bit is that it seems to me that the only use that could be made of it would be a descendant of GSE. If that does not happen, removing the 'u' bit in three years would not be more difficult nor more work than it is today. OTOH, considering the less-than-perfect status of IPv6 multihoming today, if Mike O'Dell or one of his heirs comes with a breakthrough that addresses the documented shortcomings of GSE, the 'u' bit is likely to be re-instated even if we remove it now; that would likely bring a whole new set of issues. In other words, the pros and cons about removing the 'u' bit are: Pros: If we remove it, nobody will invent something nasty that uses it. Cons: If we remove it, nobody will invent something nice that uses it. IMHO, it is a lot easier to kill a nasty project than to remove roadblocks in the way of a nice one. Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
