RE: Fourth alternative [was Re: Moving forward ....]

[<Fred.Templin@xxxxxxxxx>]

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
fred.templin@nokia.com
  

> -----Original Message-----
> From: ext Michael Thomas [mailto:mat@cisco.com]
> Sent: Wednesday, August 06, 2003 12:47 PM
> To: Tony Hain
> Cc: 'Michael Thomas'; 'Brian E Carpenter'; ipng@sunroof.eng.sun.com
> 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 majordomo@sunroof.eng.sun.com
> --------------------------------------------------------------------
> 

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