Keith Moore wrote:
What many are missing here is that this is not about 1918 style
addressing. This is about the fact that addresses do not
have the same
visibility and accessibility throughout the network.
no, it's not just about that. you are the only one who keeps
insisting that. you seem to be trying to conflate two
different notions of scope. IMHO it's clearer if you talk
about those kinds of scope in separate terms; which is why I
prefer to talk about ambiguous addresses on one
hand vs. packet filtering on the other. It happens that SLs combine
the two, but there's no inherent need to do so.
There were several proposals to remove the ambiguity in the current SL,
so continued dislike of them shows that is not the underlying issue. The
real issue is that highlighting different reachability perspectives in
different parts of the network has exposed invalid assumptions. On top
of that, scoping is about more than packet filtering, scoping happens
simply by filtering out some topology information in the routing
protocols. I agree we need to be clear about terms, but continuing to
mix ambiguity with scoping is not getting us there.
Our task is to look at the overall system the way that network
managers really run (or want to run) it, then figure out
what it will
take to make that happen.
funny, I thought our primary task was to design a network that could
support useful applications.
No that is the network managers task. One could argue that many of the
problems in making progress in the IETF are about this confusing of
roles.
of course, managability is an important
aspect of being able to support useful applications, but it
is not reasonable to constrain the v6 network design to only
permit things that are compatible with network managers'
assumptions about how to operate v4 networks.
Network managers don't assume, they define how the network operates. The
IETF is the one that assumes they can dictate ...
v6 is more different than v4 than most people realize.
I would argue that it simply takes advantage of many of the latent
capabilities that already exist in IPv4.
so no, I don't accept your definition of "our task"; in fact
I fundamentally disagree with it as stated.
I understand that, but that doesn't change the reality that the IETF is
not in the business of designing networks. The IETF is in the business
of defining the standards that allow the network manager to acquire the
tools to accomplish his role as the network designer.
I don't know what a solution looks like, but I do know that
continuing
to bury our collective head in a dark place will not make
the problem
that needs solving go away.
And as long as that's the way you characterize users and
applications writers with genuine needs, you're not going to
be able to contribute to solving the problem.
How else does one characterize the explicit refusal to deal with a known
problem for 15+ years?
Tony