ietf
[Top] [All Lists]

Re: Architectural Considerations section in specs

2003-04-23 15:06:37
What they are missing is that a defined prefix doesn't create the
problem that they are complaining about. Limiting the usable scope of
addresses is an operations decision. 

Tony, this discussion is about ambiguous addresses.  Your persistent
attempt to conflate it with packet filtering and/or routing policy isn't
shedding any light on the argument.  And you're smart enough to know
the difference.

Defining a prefix for those only made it *possible* for apps to
recognize which ones might be restricted.

But it doesn't help apps know *how* those addresses are restricted.

 It does not *make* apps deal
with the problem of leaking addresses outside their scope of relevance
(unless you take the viewpoint that end users actually expect
applications to work right, and will require it once it is possible).

Experience indicates that this is exactly what happens.  You cannot
expect apps to not leak addresses outside of their scope because apps do
need to pass addresses around and they have no way of being aware of
their scope boundaries.  The way to solve this problem is to make
addresses unique.

Applications are not required to understand topology, unless and until
they insist on passing around topology specific information. 

Another attempt at disinformation on your part.  The fact that the
current internet architecture doesn't provide us with reliable endpoint
identifiers that are independent of topology information is not a
justification for asserting that applications should not pass around the
best endpoint identifiers that are available to them.  And very few
applications use these as anything other than opaque tokens.

There is no magic here, and defining a prefix didn't change the
architecture. 

defining a prefix didn't change the architecture - asserting that the
same prefix could be reused in multiple locations did change the
architecture.

Operational decisions established the architecture, and
it is our job to define the technologies that work within that
architectural reality.

indeed.  this is precisely why we are deprecating site locals - because
they do not work within the architectural reality.

Keith