Search RPD Archives
Limit search to: Subject & Body Subject Author
Sort by:

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

JORDI PALET MARTINEZ jordi.palet at consulintel.es
Wed Apr 4 12:35:24 UTC 2007


Hi Alain,

I see you point, however, if you look to other policies, it is never
indicated how the operational aspects are being done, so I'm not sure what
it makes a difference for you in this case ?

I will say that in favor of not defining the operational aspects there is a
special consideration here: If several RIRs, adopt this policy, then they
might decide to keep a single registry. If we want to define this now, it
means extra work (considering both possibilities single and "split"
registry) to be done now, and wasting time from all those contributing to
that work (because at the end only one operational model is feasible).

Furthermore, the operation of the registry doesn't impact at all on the
policy itself, so I don't see the reason to enforce operational details in
the text. If you can describe exactly what do you think I'm missing on this
regard, that will be really helpful.

Last but not least I trust the RIRs staff in doing the right thing in terms
of operation, so again, what is your fear here ?

On the other hand, it will be good to heard the voice of the staff, if they
want specific instructions on the operational details or they prefer to work
together with other RIRs and share experiences and knowledge's (as they do
for the rest of the policies) and work out for the best solution without any
impact on the results.

One "real life" example, so everybody get the point here. In another RIR
service region (LACNIC) it was commented in the policy mailing list about
how they allocate the IPv6 prefixes and how much they reserve, as contiguous
blocks, for future allocations, and if they wanted to have that detailed in
the policy. They clearly said "no please" that will make it more complex for
us and can create unnecessary burden. Actually they were considering taking
on the expertise from RIPE NCC which already was using sparse allocation.

So what the staff prefers, having the policies with all the operational
details or leave that so they can do what is better (from the operational
perspective) and thus being able to adapt to changing situations ?

Actually this is very good point also. Fixing the operational details makes
difficult to adapt to new situations, because it will require to change the
policy, which may become slow. For example if other RIRs decide to pass this
policy and create a single registry some time after was already implemented
by AfriNIC.

Regards,
Jordi




> De: Alain Patrick AINA <aalain at trstech.net>
> Responder a: AfriNIC Resource Policy Discussion List <rpd at afrinic.net>
> Fecha: Wed, 4 Apr 2007 10:55:29 +0100
> Para: AfriNIC Resource Policy Discussion List <rpd at afrinic.net>
> Asunto: Re: [AfriNIC-rpd] New policy proposal: IPv6 ULA-central
> 
> 
>> 1) The draft introduces the concept and one way to manage this, however, in
>> section 7.0, IANA considerations, is already indicated "... If deemed
>> appropriate, the authority may also consist of multiple organizations
>> performing the allocation authority duties".
> 
> the same IANA session  also says:
> 
> "The IANA is instructed to designate an allocation authority, based on
>    instructions from the IAB, for centrally assigned Unique Local IPv6
>    unicast addresses.  This allocation authority shall comply with the
>    requirements described in Section 3.2 of this document, including in
>    particular allocation on a permanent basis and with sufficient
>    provisions to avoid hoarding of numbers."
> 
> Yes "if deemed appropriate". And if "we" think RIRs can do this do, we need to
> make 
> sure  it is done accordindly to established rules.
> others on this list have made some good points on this isssue.
> 
>> 2) Even if only L=1 is defined, the entire block is on IANA hands, as it is
>> a /7, not /8.
> 
> and you need to get the desired block(L=0) from IANA to the designated
> authority(ies). 
> 
>> 3) The definition of L=0 is done by this document. We just need to move it
>> forward again, which as said before, can be done in parallel with the PDP in
>> the RIRs. I don't think there is any rule that says "must be done in serial
>> mode" and if this helps to win time, why not ?
> 
> I am not confortable with AfriNIC adopting "the policy as proposed" without
> clarifications the issues mentionned.
> 
> --alain
> 
> _______________________________________________
> 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.






More information about the RPD mailing list