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

Wed Apr 4 13:06:56 UTC 2007

Actually, I think Adiel already replied to this question, according to the
email from Hisham:

(d) Adiel Akplogan        (15.03.2007)
Clarified that the job of determing the mode of allocation of IP
resources was a purely administrative/business process issue and that it
was the role of the Registration Service to determine how best to manage
the space allocated to AfriNIC.

Regards,
Jordi

> De: JORDI PALET MARTINEZ <jordi.palet at consulintel.es>
> Responder a: <jordi.palet at consulintel.es>, AfriNIC Resource Policy Discussion
> List <rpd at afrinic.net>
> Fecha: Wed, 04 Apr 2007 15:35:24 +0300
> Para: AfriNIC Resource Policy Discussion List <rpd at afrinic.net>
> Conversación: [AfriNIC-rpd] New policy proposal: IPv6 ULA-central
> Asunto: Re: [AfriNIC-rpd] New policy proposal: IPv6 ULA-central
> 
> 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.
> 
> 
> 
> _______________________________________________
> 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.
> 
> 

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