Umm, the draft has *two* authors - not one. The requirements and scenarios in the document are showing a *real need* independent of whether link-local, site-local, limited-range, global, provider-independent, etc etc. provide the best solution. If you think the document has a scoping issue (no pun intended), then let's discuss that with a measured tone.
Thanks, Fred Templin [EMAIL PROTECTED] > -----Original Message----- > From: ext Michael Thomas [mailto:[EMAIL PROTECTED] > Sent: Wednesday, August 06, 2003 12:47 PM > To: Tony Hain > Cc: 'Michael Thomas'; 'Brian E Carpenter'; [EMAIL PROTECTED] > Subject: RE: Fourth alternative [was Re: Moving forward ....] > > > Tony Hain writes: > > Michael Thomas wrote: > > > The problem is that this draft proceedes from the > > > premise that the answer is consing up limited > > > range addresses. > > > > It is not intended to. It is trying to point out the > requirements that > > network managers have. It uses examples where they have > found limited range > > addresses meet the need to explain it for those who don't > believe their > > requirements are real. > > Tony, quit patronizing me and everybody else. I've > not seen one person here who is insensitive to the > actual needs of network managers. What I've seen > is differing opinions of how to weigh the > conflicts and most especially what the long term > implications are of any particular approach. Your > trying to frame these conversations as a one-man > crusade against the IETF ivory-tower is lame and > insulting. > > Your draft is not helpful because it starts out > with a conclusion and works back from there, much > like yellowcake and WMD. The bias is in the title > of the draft, for gawd sake. What we really need > is something that lays out all of the requirements > -- and local scope is not a requirement, it's a > solution -- and tries to analyze the problem space > without bias to a particular solution; laying out > the good, bad and the ugly for each possible > approach. > > > > > > That's incorrect and not > > > helpful. We need to start by determining what the > > > *requirements* are, > > > > That is the point of the draft. > > It fails. See above. > > > Unfortunately some on this list want to > > argue that some requirements are not real, rather than > accept that different > > situations create different requirements. Given that not > everyone has > > expierenced every situation, the draft needs to provide > enough context > > around a requirement so that others can see the issue. > > And now your patronizing the group again. Stop it. > > > > and only then outline what the > > > range of solutions are, and what their problems > > > and possible consequences are. Until we can get an > > > consensus on what we need to do, and what the > > > engineering tradeoffs are, we will never come to > > > closure. > > > > Yes and no. There is no way to achieve a single optimal > solution for the > > diverse set of requirements, so we know the outcome will > be a compromise. > > Bob's draft (as did the others to randomize SL) meets the > requirements in > > the current draft. > > You mean the requirements of "do no harm wrt NAT > and DFZ route pollution?" Oh, golly, I guess I > didn't find those in the draft. Both of these > requirement are downsides of limited scope > addresses approach, btw. > > > > That in a nutshell is why I have a problem with > > > the religiosity on both sides of this argument. > > > > My religion is that the deploying network manger is right, > no matter what > > the IETF decides. If the IETF decides to provide tools to > make deployment > > easy, that will be the path of least resistance. If not, > the network manager > > will demand ad-hoc tools to get the job done. > > Aside from the preposterous notion that you're the > torch bearer of the poor under represented network > manager (::snort::), this isn't helpful because > what we need here is to balance out the > conflicting requirements both in whose work load > is affected, as well as the general architecture > of the net. The network manager is *one* voice > that needs to be considered, not the *only* voice. > > 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] --------------------------------------------------------------------
