[AfriNIC-rpd] New policy proposal: IPv6 ULA-central

[JORDI PALET MARTINEZ]

Hi Alan,

See below, in-line.

Regards,
Jordi




> De: Alan Barrett <apb at cequrux.com>
> Responder a: AfriNIC Resource Policy Discussion List <rpd at afrinic.net>
> Fecha: Wed, 4 Apr 2007 15:10:18 +0200
> Para: AfriNIC Resource Policy Discussion List <rpd at afrinic.net>
> Asunto: Re: [AfriNIC-rpd] New policy proposal: IPv6 ULA-central
> 
> On Wed, 04 Apr 2007, JORDI PALET MARTINEZ wrote:
>> I understand your point, but in my opinion, policies should not
>> enter into details of how they become actually implemented from an
>> operational perspective.
> 
> I agree that details should be left to the RIR staff, but perhaps we
> disagree about where broad outlines end and details start.

May be we need to understand from each other what exact details do you think
need to be outlined instead of considered as operational issues.

> 
> I'd like the proposal to at least acknowledge that coordination with
> other organisations will be necessary.  I also wonder what happens if
> the RIRs all get together and create a registry, but the IETF and/or
> IANA decides to contract the function out to some other party.  I also
> wonder what happens if multiple independent organisations all decide
> "let's start a ULA registry" but don't know about each other and don't
> talk to each other.

There is a starting point here: The IETF work is going to be advanced in
parallel with the PDP process, but IETF always instructs IANA, and IANA
always allocate to the RIRs. If that is going to change, the problem here is
a different one, not just for this policy, I guess ?

Actually one of my reasons for doing this policy proposal (in addition to
the need for this ULA-central allocations) is to avoid the risk of *other*
authorities different from the RIRs to take care of this (could be IANA
itself, but what I understood from them is that they don't have interest if
the RIRs do the job).

I think is clear that it will be a bad precedent to have an alternative
systems to the RIRs itself, right ?

If I'm not wrong, there are two possible scenarios if we adopt this
proposal:

1) IETF moving this document to RFC, which is the original idea (and this
can include specific text about the RIRs if needed). This can be considered
equivalent, I think to the original IPv6 /23 allocations to the RIRs ?

2) One more global policy for the ULA-central block, in order to get it from
IANA, similar way as the actual IPv6 /12 allocations to the RIRs.

In both cases it is clear the cooperation among the RIRs so I don't see how
it could happen that "they don't talk each other".

I believe the board could decide, in order to avoid any problem if the
proposal passes the PDP, to hold the proposal implementation until either 1
or 2 are done. In fact is not possible otherwise.

Of course, I'm happy if needed, to add any additional text in the policy
proposal that you may want to suggest to avoid that. For example:
"Implementation considerations: This policy will only be implemented once
IETF/IANA allocate the ULA-central prefix to the NRO, or otherwise, if a
Global Policy becomes ratified by ICANN board in order to allow the usage of
the prefix by the NRO".

> 
>> One more possibility could be to breakdown the ULA-central prefix in
>> several smaller chunks to be allocated by IANA to each RIR.
> 
> That goeas against the original idea that ULAs would not have any kind
> of geographical or topological significance.

May be I'm missing something, but I don't think there is any specific text
in the draft about this ? But in any case, it was just an example of a
possible way for doing so, not the only one.

> 
> --apb (Alan Barrett)
> _______________________________________________
> rpd mailing list
> rpd at afrinic.net
> https://lists.afrinic.net/mailman/listinfo.cgi/rpd




**********************************************
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.