> 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.dillon@xxxxxx> > > Responder a: <ppml-bounces@xxxxxxxx> > > Fecha: Tue, 29 May 2007 22:13:47 +0100 > > Para: <ppml@xxxxxxxx>, <address-policy-wg@xxxxxxxx> > > 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@xxxxxxxx). > > 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@xxxxxxxx). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf