That's broken. As it has been stated in previous messages
some days ago, RIR communities can do whatever they want,
especially if IETF fails.
That may be true but since the IETF is not failing, there is no reason for the
RIRs to take over any IETF functions.
I'm doing IETF work, but it is
clear that some times, for whatever reasons is too slow, or
even fails. This community has the right to bypass that if required.
What community? So far I see only you suggesting that the RIRs should usurp the
IETF role in defining Internet numbers.
And one more demonstration that this is broken: All the RIRs
did 4-byte-ASN policies when no RFCs where available. As you
can see the RIR system is still working.
Jordi, you are twisting the truth. When the RIRs passed the 4-byte ASN
policies, there were already Internet drafts working their way through the IETF
process. 4-byte ASN work was part of the charter of the IETF's IDR working
group. According to the IDR records here
http://www3.ietf.org/proceedings/05nov/idr.html
They had a goal to submit an RFC candidate document to the IESG in October 2005
which was more than a year before ARIN passed its 4-byte ASN policy. This is an
example of the RIRs working in concert with the IETF. What you are proposing is
for the RIRs to completely bypass the IETF process entirely.
So yes, I will much prefer to have an RFC, and this is the
way we are going, but nothing precludes to go in parallel, as
it has been done in the 4-byte-ASN, and probably some other
times I guess.
Your guess is not good enough. In fact, even if you manage to get an RIR to
pass some sort of ULA-C policy, it will not be good enough for most companies
who want a centrally registered address block. These companies want some
security of ownership in those addresses. They want strong assurances that
their registered allocation will stay with them for the life of the company or
the life of IPv6 whichever comes first. If ULA-C comes about through the
dubious process that you propose, then there is no guarantee that the RIRs
won't revoke ULA-C 6 months later. I would recommend that anyone needing the
guarantee of uniqueness from a central registry should apply for PI address
blocks. And if your local RIR does not offer PI IPv6 blocks, then work to get a
policy passed to do this, such as was done in the ARIN region.
And, in the worst case, if the IETF fails again on this (I'm
sure will not be the case this time), we could always go for
a global policy to instruct IANA to delegate that resource to
the RIRs.
Regards,
Jordi
De: <michael(_dot_)dillon(_at_)bt(_dot_)com>
Responder a: <ppml-bounces(_at_)arin(_dot_)net>
Fecha: Tue, 29 May 2007 22:13:47 +0100
Para: <ppml(_at_)arin(_dot_)net>, <address-policy-wg(_at_)ripe(_dot_)net>
Conversación: [ppml] [address-policy-wg] Those pesky ULAs again
Asunto: Re: [ppml] [address-policy-wg] Those pesky ULAs again
The policies for ULA-C are likely to be different from the
policies
for PI.
ULA-C doesn't exist. There is not even a current Internet draft to
define what the acronym stands for. If any RIRs create a policy on
that basis, then it will be the beginning of the end of the
RIR system.
The RIRs are supposed to be stewards, prudently managing a shared
resource.
--Michael Dillon
_______________________________________________
This message sent to you through the ARIN Public Policy
Mailing List
(PPML(_at_)arin(_dot_)net).
Manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/ppml
**********************************************
The IPv6 Portal: http://www.ipv6tf.org
Bye 6Bone. Hi, IPv6 !
http://www.ipv6day.org
This electronic message contains information which may be
privileged or confidential. The information is intended to be
for the use of the individual(s) named above. If you are not
the intended recipient be aware that any disclosure, copying,
distribution or use of the contents of this information,
including attached files, is prohibited.
_______________________________________________
This message sent to you through the ARIN Public Policy
Mailing List (PPML(_at_)arin(_dot_)net).
Manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/ppml
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf