[ppml] [address-policy-wg] Re: Can the RIRs bypass the IETF and do their own thing?

[JORDI PALET MARTINEZ]

Michael,

If you know about the IETF process, you will also know that the proper venue
for ULA-central ID discussion is ipv6 at ietf.org. The draft belongs to there
and the original authors are working in a new submission (as I already
indicated in other RIRs mail exploders).

If you care about the details of that document, discussion should take care
there (ipv6 at ietf.org).

This doesn't precludes on discussion in parallel the related policy
(proposal), in those RIR service regions where it has been submitted (not
yet here at ARIN, but I will do soon).

Regards,
Jordi




> De: <michael.dillon at bt.com>
> Responder a: <ppml-bounces at arin.net>
> Fecha: Wed, 16 May 2007 10:59:31 +0100
> Para: <ppml at arin.net>
> Conversación: [address-policy-wg] Re: Can the RIRs bypass the IETF and do
> their own thing?
> Asunto: [ppml] [address-policy-wg] Re: Can the RIRs bypass the IETF and do
> their own thing?
> 
>   Was: To: ietf at ietf.org; ppml at arin.net; address-policy-wg at ripe.net
> 
>>> The US DoC has as much say for ARIN as it does for the RIPE NCC.
>> 
>> The US DoC, through IANA functions, says, e.g., what IP Address blocks
>> each can allocate.  That seems to qualify as 'much say'
> 
> So it seems that you and Ray are in agreement. All the other details are
> not terribly relevant to RIR policy discussions because we have
> processes
> and structures to make sure that everything is done properly. We have no
> plans to change any of the structures because at the present time, they
> seem to work OK.
> 
> As for the matter that started this, central ULAs, there is not need to
> worry about who controls what. The fact is that it is customary for new
> address types to be defined *FIRST* in the IETF and even if there is the
> possibility of an alternate process, we would not dream of exercising
> that
> unless the customary process, via the IETF, had broken down.
> 
> The IETF process cannot be considered broken just because a draft has
> expired. In fact, expiry of a draft indicates that the original authors
> no
> longer care enough about the matter to progress it further. The WG chair
> of IPv6 Operations has already offered the v6ops list
> http://www.ietf.org/html.charters/v6ops-charter.html
> For those people who *DO* wish to progress a draft for Central ULA
> addresses. This is a sign that the IETF process is open for business in
> this case.
> 
> At this point, I think it is inappropriate to continue the Central ULA
> discussion on the RIR policy lists. In fact, if any policy were to come
> out of such a discussion, I would vote against it even though my company
> could potentially benefit from something like a Central ULA address
> block.
> But at the same time, my company supports the IETF process in general
> and
> I don't believe we would want to be perceived as usurping the IETF. That
> is why I would vote against any policy proposal that is not based on an
> RFC.
> 
> I urge all of you who have an interest in Central ULA addresses, both
> pro
> and con, to take your discussion to the v6ops list. And I urge the
> people
> in favour of Central ULA addresses to write an Internet draft explaining
> just what it is that you want to do. At this point in time, there is no
> valid draft document so I don't even know what it is that you are
> discussing.
> 
> --Michael Dillon
> 
> 
> _______________________________________________
> This message sent to you through the ARIN Public Policy Mailing List
> (PPML at arin.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.