[AFRINIC-rpd] Questions about IPv4 Allocation Policy AFPUB-2005-v4-001

[McTim]

On Wed, Nov 13, 2013 at 4:15 AM, Keshwarsingh Nadan <
keshwarsingh.nadan at millenium.mu> wrote:

> Dear Community,
>
> I realize that this isn't the proper list for this specific question, but
> since there isn't another active list to post to, I'm posting it here.
>
> I need the authors comment as well as members.
>
> Section 7.3 of the IPv4 Allocation Policy states the following:
>
> In order to properly evaluate requests, an RIR must carefully examine all
> relevant documentation relating to the networks in question. Such
> documentation may include network engineering plans, subnetting plans,
> descriptions of network topology, and descriptions of network routing
> plans.
> All documentation should conform to a consistent standard and any estimates
> and predictions that are documented must be realistic and justifiable.
>
> Section 8.4 of the IPv4 Allocation Policy states the following:
>
> An LIR may receive an additional allocation when about 80% of all the
> address space currently allocated to it has been used in valid assignments
> and/or sub-allocations. A new allocation can also be made if single
> assignment or sub-allocation requires more addresses than those currently
> held by the LIR.
>
> Reservations are not considered as valid assignments or sub-allocations. It
> may be useful for internal aggregation to keep some IP blocks free for
> future growth. These internal reservations are however not counted as valid
> usage and must be assigned or sub-allocated before requesting for an
> additional allocation.
>
> AFRINIC will always try to allocate contiguous address ranges, allowing the
> LIR to minimise the number of route announcements it makes. However, it
> will
> not always be possible to allocate a range contiguous with the LIR's
> previous allocation.
>
>
> Based on above sections of the policy, I, LIR-AAA needs another allocation
> since I ran out of IP space for the following reasons:
>
> a) I provide hosted services such as accounting / crm / erp on a Software
> as
> a Service (SaaS) basis.
> b) I am utilizing more than 80% of my previous allocation in valid
> assignments, which is assigned to my infrastructure since the IP space is
> being
> used to provide SaaS based service.
>
> Business Model:
>
> - CLIENT-BBB leases / outsources hosted service from LIR-AAA.
>
> - CLIENT-BBB resells the leased / outsourced hosted services to their own
> client, CLIENT-CCC.
>
> - CLIENT-CCC resells the hosted services purchased from their supplier
> CLIENT-BBB to their own customer base and the public in general.
>
> For facilitating evaluation procedures, LIR-AAA exceptionally granted
> AfriNIC a remote access to its infrastructure though a live remote session
> since AfriNIC hostmasters primarily liaise with LIRs in the telco industry,
> AfriNIC needs to fully understand:
>
> - The business model.
> - Why the service requires a whole IP space.
> - How the service works.
> - Peak sessions.
>
> AfriNIC insists that in order for LIR-AAA to comply with the current
> policy,
> AfriNIC needs to establish the existence of the end-users, i.e. CLIENT-CCC
> customers. Information requested:
>
> - Name of companies.
> - Physical address.
> - Contact persons.
> - Email addresses.
> - Phone numbers.
> - Contact them if necessary.
>
> Everyone seems to interpret the policy in his/her own way. In short:-
>
> - Is AfriNIC allowed to request such information for evaluation purposes
> according the current policy based on my business model, i.e. offering SaaS
> based services?
>


IMHO, yes.  But your biz model doesn't matter.  It's the usage of IP
addresses that matter.


> - Is AfriNIC generally allowed to request such information for evaluation
> purposes according to the current policy ?
>



see above.



-- 
Cheers,

McTim
"A name indicates what we seek. An address indicates where it is. A route
indicates how we get there."  Jon Postel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20131113/d10d2d00/attachment.html>