[AfriNIC-rpd] Updated Version of the "IPv4 Soft Landing Policy" now Available Online

Tue Feb 22 15:11:11 UTC 2011

--- On Mon, 2/21/11, Owen DeLong <owen at delong.com> wrote:

> From: Owen DeLong <owen at delong.com>
> Subject: Re: [AfriNIC-rpd] Updated Version of the "IPv4 Soft Landing Policy" now Available Online
> To: "James Blessing" <jblessing at llnw.com>
> Cc: rpd at afrinic.net
> Date: Monday, February 21, 2011, 10:51 PM
> 
> On Feb 21, 2011, at 6:00 AM, James Blessing wrote:
> 
> > On 21/02/2011 09:53, Mukom Akong T wrote:
> > 
> >> [3] The Proposal
> >> 
> >> This policy (IPv4 Soft Landing), applies to the
> management of address
> >> space that will be available to AfriNIC after the
> current IPv4 pool is
> >> depleted. The purpose of this document is to
> ensure that address space
> >> used in a manner that is acceptable to the AfriNIC
> community especially
> >> during this time of scarcity.
> > 
> > Wording here seems to be in the wrong tense (or
> incorrect)
> >

Any Clarifications or/and suggestions?

> >> AfriNIC will publicly announce that the Exhaustion
> Phase has begun at
> >> this point.
> > 
> > Add "For the avoidance of doubt all applications that
> are currently in the process at this point will be evaluated
> as per the new policy."
> > 

Incorporated

> >> 3.5 Exhaustion Phase:
> >> 
> >> During the Exhaustion Phase, the following
> allocation and assignment
> >> policy will be used. This policy applies to both
> LIRs and End Users, and
> >> applies at all times after the transition to the
> Exhaustion Phase.
> > 
> > Why does this apply to EU and LIR, surely this policy
> is for LIRs only
> > 
> It most certainly needs to apply to EU as well unless the
> change you
> are suggesting below is made.

Any reason you think it shouldn't be for EU/LIR? We have made the Min/Max sizes of allocation/assignment flexible enough to cater for both 

> 
> >> The exhaustion phase will be divided into two
> parts:-
> >> a) Exhaustion Phase 1
> >> b) Exhaustion Phase 2
> >> 
> >> 3.5.1 Exhaustion Phase 1
> >> During this phase, allocation/assignment of
> address space will continue
> >> as in the Current phase (/24 for a EU and /22 for
> a LIR) but the maximum
> >> will change from /10 to /13.
> >> 
> >> Allocations and assignments will be made from the
> /8 pool until we reach
> >> a /11. At this point the Exhaustion Phase 2 phase
> will kick in.
> > 
> > Again add "For the avoidance of doubt all applications
> that are currently in the process at this point will be
> evaluated as per the new policy."

We are technically using the same policy :-) - You have a point though. i will think up some more appropriate wording.

> > 
> >> Exhaustion Phase 2
> >> During this phase a minimum allocation/assignment
> size will be /27. And
> >> a maximum of /22 per allocation/assignment.
> > 
> > I think that this is a bad idea as it will increase
> the memory tables of routers disproportionately. Could this
> not remain at /24?
> > 
> I think this is inevitable after runout. IPv4 routing
> tables are going to grow
> substantially as a result of the address trading policies
> in other regions
> and this will not be a significant portion of the routing
> tale growth.
> 

Agree.

> >> 3.6) If any LIR or End User requesting IPv4
> address space during the
> >> Exhaustion Phase does not already have IPv6
> address space, then AfriNIC
> >> shall allocate or assign an IPv6 address block in
> compliance with the
> >> IPv6 allocation or assignment policies in effect
> at the time.
> > 
> > Why? Surely the LIR should have applied and completed
> the process of obtaining a IPv6 allocation/assignment before
> applying... (this should be a Phase 1 requirement)
> > 

There was consensus earlier that and RIR is not supposed to dictate what Technology...etc you use....but we can encourage v6 adoption by availing the address space.

> >> 3.7) The current allocation and assignment period
> of 12 months shall be
> >> changed to 8 months. This will help to ensure that
> LIRs request only for
> >> resources they need in the short to medium term,
> and promote fairness in
> >> the equitable distribution of the last IPv4
> address pool.
> > 
> > Is this meant to in Phase 1 or Phase 2 - the numbering
> of the document is not clear.
> > 
> I think it should apply throughout both phase 1 and phase
> 2.

It is for both Phases. Maybe for clarity i can add something like

This assignment period will remain the same throughout the life span of this Policy

> 
> >> 3.8 Allocation Criteria
> >> 
> >> In order to receive IPv4 allocations or
> assignments during the
> >> Exhaustion Phase, the LIR or End User must have
> used at least 90% of all
> >> previous allocations or assignments (including
> those made during both
> >> the Current Phase and the Exhaustion Phase). In
> the case of new LIRs or
> >> End Users with no previous allocations or
> assignments, this requirement
> >> does not apply to their first allocation or
> assignment request.
> > 
> > Is this for clarification, this should be 90% of the
> aggregate space assigned or allocated rather than 90% in
> each separate assignment/allocation
> > 
> I would read that as 90% of the aggregate overall, not
> individually 90% of
> each. I don't think clarification is needed. I think it
> would be hard to construe
> the existing wording to mean 90% of each separate
> allocation.
> 
> 
> >> 
> >> AfriNIC resources are for the AfriNIC geographical
> region. For each
> >> allocation or assignment made during the
> Exhaustion Phase, no more than
> >> 10% of these resources may be used outside of the
> AfriNIC region, and
> >> any use outside the AfriNIC region shall be solely
> in support of
> >> connectivity back to the AfriNIC region.
> > 
> > How is this measured? What counts as 'outside'?
> > 
> AfriNIC has a clearly defined geographical service region.
> If an address is
> assigned to a device physically outside of that defined
> region, then, the
> address is being used outside of the region. This does not
> seem like
> rocket science to me.
> 
> Determining this may be a bit more complex, but, I do not
> believe that
> we should focus on the difficulty of implementing the
> policy, so much
> as we should clearly state the desire and intent of the
> community.
> Having done so, in reality, most of our policies depend
> entirely on
> voluntary compliance anyway, so, this one will not be
> significantly
> different.
> 
> >> 3.9 IPv4 Address Space Reserve
> >> 
> >> A /12 IPv4 address block will be in reserve out of
> the Last /8. This /12
> >> IPv4 address block shall be preserved by AfriNIC
> for some future uses,
> >> as yet unforeseen. The Internet is innovative and
> we cannot predict with
> >> certainty what might happen. Therefore, it is
> prudent to keep this block
> >> in reserve, just in case some future requirement
> creates a demand for
> >> IPv4 addresses.
> > 
> > How does this impact with the /11 in 3.5?
> > 
> > Would a better approach not to be take a /12 from
> existing space, set it aside as 'future use' and then change
> the /11 in 3.5 to a /12?
> > 
> I think both approaches have the exact same effect and it
> is much easier to
> express in policy in the current manner.
> 
> >> 3.9.2
> >> When AfriNIC, can no longer meet any more requests
> for address space
> >> from the last /8 pool because the pool is either
> empty or has no more
> >> contiguous blocks, the Board will based on the
> demand and other factors
> >> at the time exercise their prerogative to
> replenish the exhaustion pool
> >> with whatever address space that will be available
> to AfriNIC at the
> >> time in a manner that is in the best interest of
> the community.
> > 
> > I suggest this is striken from this policy and added
> to another.
> > 
> I think it's fine here, but, thinking more about it, I
> would suggest rather
> than "prerogative to replenish" I would suggest "discretion
> and may 
> replenish". The current wording forces the board to
> replenish, even
> if it may bankrupt the organization. I do not believe that
> is the intent
> of the community.

Noted
> 
> 
> Owen
> 
> _______________________________________________
> rpd mailing list
> rpd at afrinic.net
> https://lists.afrinic.net/mailman/listinfo.cgi/rpd
> 