[AFRINIC-rpd] Latest version of the policy AFPUB-2013-GEN-001-DRAFT-03

[Owen DeLong]

A nit, but if we are going to use part time students *.5 to compute the address ration, then shouldn't section 3.1 include a proof of the number  of part time students in the required documentation?

I doubt such is likely to be abused, but for the sake of completeness and accuracy and consistency of the policy document, I believe this small change should be made.

More substantive:

As the policy is written, it leaves dangling ambiguously defined terms. In some jurisdictions, the term higher education may mean any college. In other places, it means only four year universities. In yet others, it means only institutions offering postgraduate work. I see no benefit to this policy excluding primary and secondary educational institutions and I see no reason that the less ambiguous term "Academic Institution" should not be used. As such, I suggest:

1.	s/HEI/Academic Institution/g
2.	s/Higher Education/Academic/g

I suggest simplifying 3.5-3.7 as follows:

3.5) Under the policy, Academic Institutions shall be eligible to receive up to 5 IPv4 addresses per campus user (as defined in 3.2) without need of further documentation.

3.6) With additional documented need, an institution may receive as many as 10 IPv4 addresses per campus user (as defined in 3.2).

3.7) An institution may request any amount of addresses and may make multiple requests until such time as their total amount of resources received is equal to the maximums defined in sections 3.5-3.6.

Further, I believe that section 3.8 is too lose. I suggest modifying as follows:

3.8) Academic Institutions will be classified as End Users under this policy, so long as they are able to prove that the addresses are not used to number network elements not administratively controlled directly by the institution. An Academic Institution which cannot provide such proof may still receive an allocation under this policy, but will be treated as an LIR.

I'm unclear as to the purpose of section 3.9.

First, it is not clear in this policy whether or not an academic institution can choose to apply under other policies.
Second, I question whether a further discount beyond the "LIR-style addressing for End User pricing" already contemplated in section 3.8 should be allowed or permitted.

Finally, section 3.10 is superfluous and should be deleted as such. It does not say anything which is not covered in section 3.1.

I remain neutral on the policy over all, though I do like the IPv6 requirements in sections 3.3-3.4.

Owen

On Jun 24, 2013, at 00:26 , Andrew Alston <alston.networks at gmail.com> wrote:

> Hi All,
> 
> Please see the proposed modified version of the policy as requested by community consensus at the Zambian PDP Meeting.
> 
> Thanks
> 
> Andrew
> 
> 1) Summary of the Problem Being Addressed by this Policy Proposal
> Given that the Higher Education Institutions (HEIs) in Africa are growing, and that Internet access within these Higher Education Institutions is critical to the educational experience of students, it is necessary to provide sufficient address space to these HEIs to allow them to function effectively.  When we consider that such institutions are constantly upgrading their Infrastructure and bandwidth to support technologies which are severely limited in environments using Network Address Translation (NAT), we believe that it is important that HEIs desirous of public address space should have the ability to migrate away from NAT. Such migration will help promote technologies such as multicast and the convergence of voice and data networks, which will in turn drive down the costs within such institutions.
> By promoting the elimination of NATs, this proposal will also assist HEIs in their migration to IPv6, and in fact, to qualify under this proposal, dual-stack and/or rollout of IPv6 at the qualifying institution is mandatory.
>  
> 2) Summary of How this Proposal Addresses the Problem
> a) This proposal will simplify the allocation of address space to HEIs by detailing and simplifying the address justification criteria b) This proposal recognises HEIs as end users, and removes the confusion previously seen where arguments have occurred as to the status of the applying institution. c) This proposal helps to reduce the dependence of HEIs on NATs, and is in line with AfriNIC's own policy of not promoting the usage of such translation mechanisms.. d) This proposal encourages the adoption of IPv6 by making the rollout of IPv6 a criterion for qualification under this proposal.
>  
> 3) Proposal
> Higher Education Institutions qualify for IP address space from AfriNIC based on the sum of the number of registered students and employees on their campus. 
>  
> 3.1) To qualify for address space, Higher Education Institutions will need to apply as end users and provide the following documentation:
> 3.1.1) Proof of Institution's registration/accreditation   3.1.2) Proof of the number of registered full time students 3.1.3) Proof of staff head count.
>  
> 3.2) This policy applies a ratio to a head count of campus users, where the number of campus users is calculated using a formula of full time students + full time employees + (part time students * 0.5)
>  
> 3.3)  In addition to the documentation specified in clause 3.1, institutions will need to provide details of planned/current IPv6 roll-outs, including committed time frames for the roll-out of IPv6.
>  
> 3.4) For the purposes of this policy, the roll-out of IPv6 can only be considered to be a true IPv6 roll-out, if IPv6 is extended to the edge of the network, beyond just the core/server infrastructure.
>  
> 3.5) Under the policy, HEI shall be eligible to receive IPv4 resources at a ratio not less than 5 IPv4 addresses per campus user, where campus user is defined in 3.2).
>  
> 3.6) While 3.5 defines a minimum accepted ratio for which the justification is clearly defined in 3.1, applications based on a ratio as high as 10:1 shall be given due consideration and should be approved unless the justification for such increased ratio is believed by AfriNIC staff to be specious or fraudulent in nature.
> 
> 3.7) While 3.5 defines a minimum ratio for which institutions shall be eligible, where an institution believes that it requires less space than defined by this ratio, a ratio of less than the 
> default specified in 3.5 may be requested.
>  
> 3.8) HEIs will be classified as End Users under this policy, on provision of a duly authorised letter from the institution management stating that address space allocated will not be used outside of the campus/academic environment.
>  
> 3.9) HEIs qualifying under this proposal will qualify for the same academic discounts that are applicable to any academic institution at the time of application.
>  
> 3.10) Since any HEI that has a large base of registered students and full time staff, has to, by the very nature of their function, have equipment on campus, this policy dispenses for the need for a HEI to provide detailed proof of equipment and infrastructure.
>  
> 
> Revision History (For all but the first draft)
> Version 1 – Added 3.1.3 to include justification of employee count. Added a new point 3.2 and 3.4, meaning that sequential numbering changed, where the original 3.2 became 3.3, 3.4 became 3.5, 3.6 was a new point, meaning original 3.6 -> 3.8 became 3.7 -> 3.9. Added 3.2 to define the calculation of head count to which the address ratio calculation is applied.  Modified 3.5 to change the ratio from 1:3 to 1:5 as per requests from the RPD list. Added 3.6 to allow for allocations larger than the de-facto 1:5 ratio upon submission of additional documentation, while maintaining the need for minimal justification if the ratio applied for did not exceed the 1:5 mark.
> Version 2 - Added point 3.7 to allow for smaller applications.  Renumbered 3.8 -> 3.10 (from 3.7 -> 3.9). Replaced the word "academic" with the term "Higher Education Institutions" where appropriate to make the policy more consistent 
>  
> _______________________________________________
> rpd mailing list
> rpd at afrinic.net
> https://lists.afrinic.net/mailman/listinfo.cgi/rpd

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20130625/c90a703c/attachment.html>