Michael, Sorry, but I think you are dead wrong, and you are moving us backward and risking another year or two of wasted time.
There is nothing new in this whole argument. As I pointed out in the IAB architecture session in Vienna, these issues have been around for 6 years at least. We know what we can do with today's routing mechanisms, today's renumbering mechanisms, and today's security mechanisms, and that leads *directly* to the requirements in the Hain/Templin draft, and IMHO *directly* to the solution in the Hinden/Haberman draft. I think we are way past the point in history where it is fruitful to make the sort of free-space wish-the-world-was-different analysis you are advocating. Hinden/Haberman leads to simple, straightforward changes to shipping code and that's all we can afford now. Brian - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM NEW ADDRESS <[EMAIL PROTECTED]> PLEASE UPDATE ADDRESS BOOK Michael Thomas wrote: > > [EMAIL PROTECTED] writes: > > If you think the document has a scoping issue (no pun intended), > > then let's discuss that with a measured tone. > > Yes, I think it has scoping issues. A name change, > for starters. It should first lay out requirements > of network operators, etc in terms of what they > need to accomplish not how they can accomplish it. > Take as a very large for example, address > stability. That's not the requirement, per > se. What they want is for topology tweaking to not > adversely affect running applications. However > protocols such as TCP are incapable of sustaining > sessions across address changes which is typically > needed when you want to move topology around. > That's the reason I say that "stability" is a > solution, not a requirement. Keeping addresses the > same is *a* way of keeping applications from > breaking, but not the only one. Mobile IP > obviously comes to mind, and there are other ways > we could envision like Fred's attempt at > operational renumbering. > > Another example is your "well known prefix". I'd > think that the requirement is that certain > services and/or classes of devices need to be > isolated and/or invisible from the other parts of > the net. A well known prefix is a way to do that, > but it doesn't necessitate local scope and again > isn't the only way to wall stuff off. > > I really don't want to drag this into a meta > argument about the merits of various solutions, > but only to point out that the entire document is > structured in a way that the answer is foregone. > That's not what we need right now. We need > something that tries to be unbiased about the > ultimate compromises we're going to have to make > by saying what we want (requirements), what the > possible frameworks are for addressing the > requirements, and most especially what their > possible downsides are. We don't need boosterism > which tries to paper over the warts; all possible > solutions have problems, what we need is an honest > evaluation so that we can decide which path is the > least objectionable. > > Mike > -------------------------------------------------------------------- > 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] > -------------------------------------------------------------------- -------------------------------------------------------------------- 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] --------------------------------------------------------------------
