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. 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.
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, ARIN saw fit to allow
PI for IPv6 anyway, with potentially very harmful long-term results.
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". 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. 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. (Maybe that also
explains the differences in the financial situation between the RIRs
and the IETF...)
if
you feel that an RIR policy is wrong, then the correct
place to "fix" it is within the RIR community. In ARIN's
case, the public-policy mailing list is where you can post
your concerns so that they will be heard by the operational
community and you can persuade them that their operational
practices are "second-guessing" IETF design decisions.
Good luck with that.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf