On Sun, 24 Aug 2003, Tony Hain wrote: > > This document seems to take for granted that local-use addressing is > > needed. Moreover, it lists requirements for every possible case where > > local-use address could be applied to (and, not for example, those > > cases where the local-use addressing is really necessary). > > Necessity is both the perception of the network manager in trying to > implement a local policy, and the availability of alternatives that > actually fit all of the local constraints.
It may not be our business to enhance misguided perceptions of the network managers, rather than correct them. > > Process questions: > > > > 1. Shouldn't we first see the requirements for site-local > > replacement (and other issues) and not jump straight to the > > requirements for local addressing? > > I don't understand the question. My original draft started from the > premise that the WG should at least have the requirements for local > addressing before deciding that any given technology is either > acceptable or unacceptable. Site-local is a specific technology that > meets many of the needs of local addressing, but creates other problems > through its ambiguity. Getting rid of ambiguity does not remove the > requirements for local addressing. The ambiguity was just one reason to get rid of site-locals, and I believe a non-ambiguous version is already being worked at. However, my point is that we should not be advocating local-use addresses. It is far from clear where they're actually needed, and where they're actually the best solution. I.e., I think there was some sort of consensus in the SF IETF meeting that there is a need to do at least *something* after we deprecate site-local addressing; there are some scenarios where SL's were being imagined to be used -- and now we should figure out how to address the needs of those scenarios *in general terms*, rather than jumping straight to the requirements for local addressing. It might just be that we don't need local addressing in all of those scenarios (actually, I'm certain of that). > > 2. Then if we see that local addressing is required to do X, > > see that > > this document covers X adequately? > > If the goal is to design specific approaches for every scenario, then > this suggestion would be appropriate. The goal of the requirements > document at the moment is to aggregate multiple needs under a single > technical approach. If the WG decides that multiple approaches make more > sense, then there will need to be multiple requirements documents. Agree. Note that I'm not really strongly advocating separate documents, but that we AT LEAST figure out why such-and-such requirements are there. > > I don't send in more detailed comments on the draft, because > > I pretty much > > disagree with everything it says. > > I understand your network does not have these requirements, and if we > required everyone to implement local addresses I could understand some > degree of concern. What I don't understand is why you believe it is > appropriate to tell another network manager that his stated requirements > are invalid. I do not want a cure that is worse than the disease. That is, if we make local-use addresses work "too well", and applicable also in scenarios where it isn't needed -- people go for locals and not globals. That would be a serious disadvantage for IPv6. > > Just two notes: > > > > 3.1 -- "Network managers have stated, and historical experience has > > shown, that there is a need for addresses that do not require public > > registration." > > ==> there is no supporting evidence of this expect vague > > statements. > > Please be more explicit as I don't see how we can take this for given. > > Chasing down quotes is not appropriate. If you want to see more text about > people grabbing random space from documentation or currently using 1./8, I > suspect we can come up with that. I fail to see how this leads to the requirement for non-publicly-registered addresses. What's the problem with public registration? Perhaps there is just a problem how that has been done with IPv4. [snip] -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- 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] --------------------------------------------------------------------
