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

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

Fred.Templin@nokia.com 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.

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