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

[AFRINIC-rpd] Academic IPv4 Allocation Policy Second Draft (AFPUB-2013-GEN-001-DRAFT-02)

Andrew Alston alston.networks at
Thu Jan 17 00:06:13 UTC 2013

Hi Seun,


See comments inline


We are getting closer...however i think we have not yet arrived at the
appropriate formula ;) I don't see the justification for the formula that
have given need for the 0.5 for part time students. My argumenet is; whether
the student is part time or not, whenver he/she comes on the network he get
assigned a single (full IP) and so there would be no basis for reducing the
actual number of part-time students to 50%. Actually as a matter of fact,
there is the chance that part time students may even stay longer on the
network than the full timers....due to the flexible timing schedule they may
Similarly i don't think adding full time to the employees will be
applicable....some lecturers are on contract basis, and so cannot be
refeered to as full timers. In view of all this, i am reccommending a
re-wording as follows
.....a formula of full time students + employees + on site part time


Agreed on this, I think before we make another modification though I'd like
to hear more views from the list as this seems to be the most controversial
point here.


3.4) For the purposes of this policy, the roll-out of IPv6 can only be
considered to be a true IPv6 roll-out PLAN, if IPv6 is extended to the edge
of the network, beyond just the core/server infrastructure.


Agreed on this point, no problem changing this to PLAN so long as we add
something about the time frames attached to that plan.  If an institution
says they have a plan, but its 15 years away, it's not going to help us.  So
that needs some discussion as well. 

3.6) While 3.4 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.

I am not sure about the "should be approved" part....perhaps it can read as

...applications based on a ratio as high as 10:1 will be considered for
approval by the Afrinic staff based on the justification provided by the

I don't see an issue in changing this as suggested.  So long as we don't
change the minimum standard with its low level of justification.

3.7) HEIs will be classified as End Users under this policy, on provision of
a duly authorized letter from the institution management stating that
address space allocated will not be used outside of the campus/academic


I don't think there is a need for 3.7 since it is no longer a debate on
whether HEIs is an End user or not.

Personally, while this line may be overkill, I would prefer to leave it in
since it avoids any possibility of argument later.  It does not actually
hurt to have it specifically defined.  Thoughts?

3.9) 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 networking
equipment on campus, this policy dispenses for the need for a HEI to provide
detailed proof of the equipment and infrastructure.


This one I have more issues with.  I removed the need for proof here to
avoid ANY subjective discussion.  The moment we change the wording as
suggested, we get back into the same subjective nature of things we sit with
at the moment.  I believe strongly that any HEI that has a healthy student
base and staff compliment in the modern world will by definition have
equipment to use the address space on, or at the very least, be in the
process of expanding to such equipment.  The moment we change the wording to
the suggested text, it reintroduces subjectivity and creates ambiguity that
could later become cause of arguments between AfriNIC and the institutions.
Hence, I would request that this change NOT happen, but again, I'm open to
hearing more community thought on this.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the RPD mailing list