[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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

 > > 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.

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 majordomo@sunroof.eng.sun.com