[ppml] 2005-1 or its logical successor

[Tony Hain]

Paul Vixie wrote:
> ...
> #
> # True, though if things get too out of hand the bunch at the UN has the
> # regulatory power to encourage conformance.
> 
> um, no.  actually, the UN does not have (and should not have, and will
> never
> have) that kind of regulatory power.

As the UN true, but the membership has those powers within their own
sovereign realm. All they need to do is convince each other to play along.

> 
> # I am not suggesting we should allow things to get there, just noting
> that
> # there is a boundary condition in that direction.
> 
> in an earlier note i tried to point in the general direction of the
> absurdity
> of "boundaries", but i was apparently too subtle.  if the IP community
> were
> to seek regionalized aggregatability in its block allocations, then "geo"
> is
> not what the end users would want.  indeed, you'd see outer blocks based
> on
> language, culture, religion, and politics before you'd see much geo at
all.
> for example, much of the christian world would want to band their
> addresses
> together, and much of the muslim world.  probably so they could firewall
> each
> other off more efficiently.  an outer block for the catalan language, and
> one
> for farsi, and so on.  if the idea of aggregatability as a block
> allocation
> strategy weren't just silly madness, it would grow up to be scary madness.

Your comments seem to ignore that there are already people that reverse
engineer the RIR allocations to derive the geo-political information they
want for their firewalls. Yes power is derived from managing information
flow and every group would like simpler tools for exercising restrictions. 

In any case my comments were not about managing firewalls, they were focused
on the need for network operators to weed out the crap that unnecessarily
consumes resources in their routers. There is a direct conflict between
those that want to overlay their policy on the world and those that want the
ability to control their own resources. Right now the first group is running
amuck and the second is paying the price. The second group needs a rational
tool that will allow them to push back.

> 
> # From my perspective A6/DNAME was not as technically flawed as the
> fragile
> # DNS infrastructure that it relied on. The biggest problem with A6 is
> that it
> # seriously stresses the DNS infrastructure as compared with AAAA, and the
> # only reference experience looked more like AAAA than A6.
> 
> you've given me some insight.  A6/DNAME and the dynamic edge it would have
> enabled was too organic for you and for a lot of others.  i get it now.  i
> disagree completely, now as then, since i'm in a pretty good position to
> know
> how much stress the DNS infrastructure can take, and i'll say again,
> A6/DNAME
> would have been the smaller worry compared to massive PI allocations or
> SHIM6.

If you will recall I chaired the meeting because I had the neutral position,
but that is somewhat irrelevant at this point. 

There are always going to be conflicting perspectives and people will tend
to favor the approach that draws on their experience base. This often (but
not necessarily in your case) causes them to overlook or under appreciate
the pain that approach will cause from another perspective. PI, Shim6, and
A6 all solve different problems. They are related in that they have roots in
multi-homed sites, but one solves edge autonomy, one application
persistence, and the other core flexibility. Using any one to address the
concerns of the others receives howls of incompetence. 

> 
> # In any case it is not dead so much as parked waiting for someone to show
> # that it won't break everything.
> 
> no, actually, it's dead.  there's an installed base that begins its flows
> with AAAA lookups which we've proved cannot be synthesized based on A6
> data.
> there was only one opportunity to fix this, and the "DNS Directorate"
> ruled
> it out.  (invalidating the installed base isn't on the table.)
> 
> # > but we digress.
> #
> # Your arguments are fundamentally opposed to each other here. This
> comment
> # says regulation is appropriate at a city scale while the one above about
> # intercontinental transit should not be regulated.  Why shouldn't there
> be a
> # global requirement for exchange based peering on whatever scale makes
> sense?
> 
> regulation of this kind makes sense to a group of citizens if they can get
> away with it.  the largest civic unit that can get away with stuff like
> this
> is a city.

Viewed from the bottom up. Regulators often view from the top down, so
countries fit more in their perspective of scale. I am not suggesting that
regulation is the right path, just that if it exists it will probably have
broader reach.

> 
> # Should there be a single exchange for each of San Francisco, San Jose,
> and
> # Oakland, or one that covers the entire Bay Area, or California?
> 
> if those cities could somehow learn to work together, and "get away with
> it",
> then it would be a fine thing.  but they never will, so it doesn't matter
> what "should" be done, even if we could identify the values and valuer
> that
> underlies the "should" in your question, which we can't.
> 
> # My argument is that the cost of running independent exchanges and
> transit
> # should be weighed against the cost of routing impact within that area.
> 
> weighed by whom?  googling for "soviet central planning" is entertaining
> and
> educational.  especially
> <http://www.ssc.upenn.edu/east/spring95/levin.html>,
> whose title is "Why Soviet Central Planning Failed".  here's a quote:
> 
>       In Schumpeter's view, the power of the market system lay not in the
>       level of static efficiency that it achieved (as most of the
> economics
>       profession said it did), but in its level of dynamic efficiency.
> That
>       is, the success of the market system was not its efficient resource
>       allocation under static levels of technology and resource
> availability,
>       but its ability to produce dynamic changes in technology and to
> achieve
>       dynamic growth through such changes.

Interesting in that you are essentially arguing that central planning
through the ISP/RIR process is mandatory even though it can't deal with the
dynamic needs of the end network users.

> 
> # > well, but, you are.  acting that way, that is.
> #
> # I will try to act differently, but it is hard to teach an old dog new
> tricks.
> 
> i understand that padlipsky's "elements of networking style" is back in
> print,
> and reading this could help you with your quest.

I will look for it. ;)