Thus spake "Iljitsch van Beijnum" <iljitsch(_at_)muada(_dot_)com>
On 29-aug-2007, at 22:21, Bill Manning wrote:
"the" RIRs are membership organizations, with members
consisting of the operational community. they have to
try and work with whatever the IETF gives them.. and when
what the IETF provides is not operationaly feasable, they
can and will make changes so that an operational network
exists.
In the IETF, you need rough consensus to make decisions. I'm
not entirely sure how this works in all the RIRs, but I think at least
for ARIN, there is some form of voting involved.
ARIN operates on consensus as well. The Advisory Council is tasked with
judging consensus similar to the IETF's WG chairs, as well as ensuring the
process is followed. Technically the Board votes on policy changes but,
with a few notable exceptions, they rubber-stamp the AC's recommendation.
The AC and BoT are filled by elections, which may be what you're thinking
of.
There are five RIRs, but the decisions they make often have
global impact, and once one RIR has taken a course of action,
the others often feel the need to follow.
Many folks participate in multiple RIRs and propose the same ideas in each,
and the RIRs do observe each others' actions and determine if they're
appropriate to adopt as well. There's major differences, though, which are
catalogued on the NRO web site.
Case in point is provider independent address space for IPv6.
For a decade, this wasn't possible because the IETF was first
studying, and after a _lot_ of effort to get things rolling, working
on, mechanisms to provide multihoming benefits without
injecting a prefix into the global routing table for each multihomed
site. Then, with something workable within reach but not quite
finished,
The spec wasn't even finished; widespread implementation was at least a
decade away, based on experience, and a solution was needed before IPv4
exhaustion -- currently projected for 2012 or so.
Also, the operational community appears to have nothing but complete scorn
for the alternatives the IETF has proposed to date. Folks pushing the IETF
proposals concentrated on telling the operators they were wrong instead of
asking why they thought what they did. As a former manager told me, "your
customers may not always be right, but they're never wrong".
ARIN saw fit to allow PI for IPv6 anyway, with potentially very
harmful long-term results.
Note that part of the motivation for PIv6 was the IETF's discussion of
ULA-C. The other part is that there is no time left to deploy any
alternative, no matter how great it may be, before IPv4 exhaustion happens.
A viable multihoming solution was/is _mandatory_ for IPv6 to get deployed
and, lacking a hammer, ARIN decided to pound their nails with a screwdriver
rather than watch IPv6 continue to flounder.
The IETF leadership never saw fit to say something about this
during the ARIN process, and the ARIN process mostly consisted
of "I'm not worried about the future and I want my PI block".
Lots of folks came over from the IETF (I won't accuse them of being
"leaders") to complain during ARIN's policy debates and they, with the help
of large ISPs, managed to stall the adoption of PI for over a year.
Even the proponents of PI are worried about the future, but we are forced to
support the lesser of two evils. Without PI, we wouldn't have any IPv6
routing tables to explode in the first place because IPv6 would become even
more irrelevant than it is today.
The RIR policy mechanisms are simply not capable of rejecting
policy changes that benefit a subset of the community, especially
any subset that is well-versed in RIR matters, if such a change is
against the interest of the community at large.
I suggest you take a closer look at the debates that occur. Many proposals
are shot down because they're believed to harm the community; many ideas
don't even make it to the proposal stage because of that. Some proposals
pass, despite obvious harm to the community, because not passing them would
result in worse harm.
The IETF isn't immune to this, but does a lot better than the RIRs
because it has a technically capable leadership rather than an
administratively capable leadership.
I'm not familiar with the organization of the other RIRs, but ARIN has two
distinct "leadership" groups, one technical and one administrative.
(Maybe that also explains the differences in the financial situation
between the RIRs and the IETF...)
The RIRs charge people for output but allow free input. The IETF charges
for contributing but gives its output away. The financial results are
predictable for both, as is the community that each is responsible to: the
IETF caters to vendors and the RIRs to operators.
S
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf