Subject: My point about the ambiguity of the question

From: "Tony Hain" <[email-masked]>
Date: Thu, 1 May 2003 10:47:55 -0700

Thomas & Erik,

These notes illustrate my point about the ambiguity of the question. 

First, one has to question how well Ted and others were informed if
their issue is all about ambiguity. We have several proposals to remove
the ambiguity in the FEC0::/10 prefix that are compatible with existing
implementations, so were their votes really about completing that work
to remove ambiguity? If so, deprecating the prefix would not be a step
toward completing that.

But to my point. As the second note shows, part of the goal of some
votes is to disallow a network manager the ability to limit access or
visibility to some of their nodes. The IETF is not in the role of
designing networks, and limiting access and visibility is an operational
issue that the IETF doesn't get to decide. 

The question was ambiguous. Individual interpretations of the outcome
drove YES votes for architecturally divergent goals, some of which are
not in the IETFs purview to decide.

Tony

Theodore Ts'o wrote:
> I certainly agree that it's all about ambiguous addresses and 
> not about about reachability.  And it's why I have to agree 
> with Keith that Site Local addresses are a bad idea, and why 
> ditching them is absolutely the right thing.

Keith Moore wrote:
> > My point was that there are topology locators that are only viable 
> > within a scope defined by the local network manager.
> 
> yes, we know this.  it's a bad idea, and we need to stop 
> pretending it's a legitimate thing to do.  that way, when the 
> network manager does this, it's his fault when things break.
> 
> network managers do have legitimate needs that must be 
> respected. this is not one of them.

---

From: Keith Moore <[email-masked]>
Date: Fri, 2 May 2003 11:39:14 -0400

> These notes illustrate my point about the ambiguity of the question. 

What they illustrate is your persistent efforts to misconstrue and
misinterpret what other people are saying.

> their issue is all about ambiguity. 

"it" depends on the context of that particular discussion, which is not
necessarily site-local as a whole.

Ambiguity is one of the issues associated with site local, not the only one. 

Even if Ted is only concerned about ambiguity, that doesn't invalidate Ted's
opinion.  Different people will place different values on different aspects of
a proposal, so they'll have different reasons for voting yes or no on a
question such as this.
 
> As the second note shows, part of the goal of some
> visibility to some of their nodes. 

As the author of the second note, I can authoritatively say that this is
a misinterpretation. 

Keith

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 2 May 2003 11:33:13 -0700

Keith Moore wrote:
> ...
> As the author of the second note, I can authoritatively say 
> that this is a misinterpretation. 

So please explain how I misinterpreted. Everything that is not about
ambiguity is about the simple ability to consistently limit access or
visibility, and identify when that is being done. 

We don't need to deprecate SL to fix the ambiguity, so the insistence
that deprecating SL fixes other things only leads to the conclusion that
this is about limiting a network manager's ability to define how his
network is run. That is not the IETF's call, so those votes are not
valid.

Tony

---

From: Keith Moore <[email-masked]>
Date: Fri, 2 May 2003 14:42:01 -0400

On Fri, 2 May 2003 11:33:13 -0700

> visibility, and identify when that is being done. 

False.  Forcing hosts or apps to do routing is about neither of these.
Forcing applications to be aware of topology is about neither of these.

Keith

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 2 May 2003 12:35:44 -0700

Keith Moore wrote:
> False.  Forcing hosts or apps to do routing is about neither 
> of these. Forcing applications to be aware of topology is 
> about neither of these.

The existence of a prefix does not force host or apps to do routing or
be aware of topology. The only way to come to that conclusion is if you
mean that network managers expect apps they deploy to behave correctly
in the presence of limited access or visibility, and the defined prefix
shows there is a mechanism to do so. 

Nothing is forcing the app to do anything, after all it could rely on a
service. Eliminating a defined prefix does not remove the expectation of
the network manager that apps will behave correctly on the deployed
network. 

Voting to eliminate a defined prefix with the expectation that the
application will then see a flat routing space is an indirect effort to
prevent the network manager from deploying local scopes through routing
or access controls. 

The IETF does not design networks, or make operational decisions.

Tony

---

From: Keith Moore <[email-masked]>
Date: Fri, 2 May 2003 15:49:17 -0400

> be aware of topology.

as long as the prefix is never used, you're entirely correct.

> The only way to come to that conclusion is if
> you mean that network managers expect apps they deploy to behave
> correctly in the presence of limited access or visibility, and the
> defined prefix shows there is a mechanism to do so. 

the prefix doesn't help apps do that.  and the very assumptions behind
use of the prefix are what force apps to do that.

> Nothing is forcing the app to do anything, after all it could rely on
> a service. 

in other words, we could create magic pixie dust if we only had magic
pixie dust...