Re: IPv6 RIR policy [was Re: IPv6 addresses really are scarce afterall]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Thus spake "Iljitsch van Beijnum" <iljitsch@xxxxxxxxx>
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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]