[sig-policy] Fw: prop-085: Eligibility for critical infrastructureassign
Thanks for your comments.
The statistics you show is correct, there are not many CI assignments these two years.
CI requirement is not large, but it's important. Since ICANN recently launched
New gTLD program, IDN and IDN ccTLD fast Track,
we can expect modest increase of new IDN TLDs and gTLDs in the next few years,
and that will coincide with our entering into final /8.
> The question in my mind relates to if 203.119/16 is 100% set aside for critical infrastructure assignments or not, given that section 11.3 doesn't actually say. If so then I struggle to see what real live problem prop-085 is going to solve. My belief is that the final /8 will have its assignment policy set and will be all consumed well before enough new critical infrastructure organisations can form and apply to use up the remaining space in 203.119/16 which would imply a restraint in the wrong direction.
>
What I understand is, even if that block is reserved and available, assignments/allocations
from that block still have to be justified according to some policy criteria.
Currently final /8 policy ONLY allow allocations, so even if there are enough space in 203.119/16 when we enter final /8,
critical infrastructure users still have no way to justify their needs using '11.3 Critical Infrastructure Policy',
they have to justify their needs under allocation policy :
9.3 Criteria for initial allocation
9.4 Criteria for subsequent allocations
Which they might have difficulty to justify, ie. they may not be able to show the need of /22.
> If 203.119/16 isn't set aside for just CI applications and other member applications can encroach on it, then I think you might want to consider that to be the low hanging fruit instead of heading toward the last /8 policy space.
>
According to the final /8 policy '9.10 Distribution of the final /8',
the final /8 doesn't mean a single stand alone /8 block, it means
'When the total remaining space in the unallocated APNIC address pool reaches a threshold of a total of one /8'
So,
If the 203.119/16 still have available space when we enter final /8, it's a component of the final /8 space,
it's reasonable to continue make CI assignments from it.
if the 203.119/16 is used up when we enter final /8, that shows the need is steady, it's reasonable
to open another block for it.
In either case, the policy have to allow it in order to make assignments.
Thanks & Regards
Terence Zhang
>
>
> On 18/08/2010, at 4:56 PM, Sanjaya wrote:
>
>> Hi Terence and all,
>>
>> 218.100.0.0/16 (IXP) is 12.5% utilized (26 assignments)
>> 203.119.0.0/16 (critical infrastructure) is 17.5% utilized (23 assignments)
>>
>> Hope this helps. Let me know if you need more information.
>>
>>
>> On 18/08/2010 4:33 PM, Terence Zhang YH wrote:
>>> Hi Gaurab,
>>>
>>> Thanks for your comments.
>>>
>>> As far as I know, according to the Resource ranges allocated by APNIC:
>>> http://www.apnic.net/publications/research-and-insights/ip-address-trends/apnic-resource-range
>>>
>>> 218.100.0.0/16 Used to make /24 assignments to Internet Exchange Points (IXPs)
>>> 203.119.0.0/16 Used to make /24 assignments to Critical Infrastructure
>>>
>>> Of course, it will be helpful if some one from the secretariat can verify that and
>>> shed some light on how many assignments have been make from that block
>>> and the utilisation rate, etc.
>>>
>>>> In case the allocation rate on the already reserved blocks are low, I'd
>>>> like to suggest that the policy add a condition that those blocks be
>>>> used before new allocations are made from the final /8.
>>>
>>> I am not quite sure what the above mean. If there are still addresses
>>> available for distribution from this block, it's pretty straight forward
>>> to make assignments from this block as long as assignments are permitted
>>> in the policy. I am not sure if that is what you mean, I am happy to add
>>> that condition if neccessary.
>>>
>>> Regards
>>>
>>> Terence Zhang
>>>
>>> ----- Original Message -----
>>>> Date: Tue, 17 Aug 2010 04:54:04 +0100
>>>> From: Gaurab Raj Upadhaya<gaurab at lahai dot com>
>>>> Subject: Re: [sig-policy] prop-085: Eligibility for critical
>>>> infrastructure assignments from the final /8
>>>> To: sig-policy at lists dot apnic dot net
>>>> Message-ID:<4C6A07DC.7040204 at lahai dot com>
>>>> Content-Type: text/plain; charset=ISO-8859-15
>>>>
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>>
>>>> hi,
>>>>
>>>> - From the secretariat, I'd like to know which are the ranges currently
>>>> used for critical infrastructure allocation and what is the allocation %
>>>> for those blocks. I can only find the IXP allocation block
>>>> (218.100.0.0/16.) but not the DNS related block, which possibly is
>>>> 203.119.0.0/16)
>>>>
>>>> In case the allocation rate on the already reserved blocks are low, I'd
>>>> like to suggest that the policy add a condition that those blocks be
>>>> used before new allocations are made from the final /8.
>>>>
>>>> This is important, because lots of routing policies are based on giving
>>>> special dispensation to critical infrastructure blocks.
>>>>
>>>> In General, I support this policy. It covers some very limited corner
>>>> cases, but nevertheless important corner cases to do with critical
>>>> infrastructure. From my reading of the proposal, it also gives
>>>> continuity to the current Critical Infrastructure policy. Though,
>>>> practically, I don't see this policy being used for allocation for a
>>>> long time in future, but the data I ask above may help us judge that.
>>>>
>>>> - -gaurab
>>>>
>>>> -----BEGIN PGP SIGNATURE-----
>>>> Version: GnuPG v1.4.8 (Darwin)
>>>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>>>>
>>>> iEYEARECAAYFAkxqB9wACgkQSo7fU26F3X2fIwCfaxn0fhdOv8kh+PsJitvSRMbW
>>>> xCAAnRFpGQq6BBhKOZV/xnDwAIPCc+cO
>>>> =/LT9
>>>> -----END PGP SIGNATURE-----
>>>
>>> * sig-policy: APNIC SIG on resource management policy *
>>> _______________________________________________
>>> sig-policy mailing list
>>> sig-policy at lists dot apnic dot net
>>> http://mailman.apnic.net/mailman/listinfo/sig-policy
>> * sig-policy: APNIC SIG on resource management policy *
>> _______________________________________________
>> sig-policy mailing list
>> sig-policy at lists dot apnic dot net
>> http://mailman.apnic.net/mailman/listinfo/sig-policy
>
> * sig-policy: APNIC SIG on resource management policy *
> _______________________________________________
> sig-policy mailing list
> sig-policy at lists dot apnic dot net
> http://mailman.apnic.net/mailman/listinfo/sig-policy