Hello,
Keiichi SHIMA / 島慶一 wrote: > Please note, I'm not saying that the current RO/RR is bad. I like RO > and the current draft seems OK but should we have more time to check > it? Return routability, in general, has been under discussion for well over a year. I think the basic idea came up over 18 months ago. Then there was BAKE and several other drafts. Then there was bu3way. Some of these have been implemented. The basic ideas are pretty well understood, and as with any protocol more experience will further improve our knowledge. > If we find a new method for RO and obsolete RR, how do we handle > already shipped RR based implementation? There may be a problem. For > example, we had (unverified) HAO in old drafts. Some implementation > support us and implement it. But it (unverified HAO) is now > obsoleted. This is a very long story. Until a protocol specification reaches proposed standard, implementations are at risk of becoming obsolete -- even after that. This has happened with practically every protocol I can think of, to some degree or another. For instance, even with IPv6, the planned TLA and SLA bits are now obsolete, even though they were planned out for a long time. To make an analogy, if you wait for the fastest processor technology before buying, you will never buy, because there is always something better on the horizon. At least we can make for compatibility, though. In this circumstance, it is a lot easier to _not use_ return routability if something else turns up, than it is to _use_ return routability, if it is not mandated. I have made several arguments why it should be mandated, and as best I can tell the strongest counterargument is that it's not standard yet, so how can we mandate it? I believe this to be a circular argument. > I think it is too early to make it MUST. It is not too late after all > of MIP6 vendors implement the draft and experient several interop > tests and all of us are convinced it is OK to go. If the behavior is mandated, and something goes wrong, I reckon we'll have to revise our understanding in the future. As it is now, it's the best we know, and it's pretty well understood. Everyone believes we will have something better in the future, and so I am trying my best to make sure the protocol is extensible for that future optimization. Regards, Charlie P. -------------------------------------------------------------------- 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] --------------------------------------------------------------------
