Re: [sig-policy] prop-129-v001: Abolish Waiting list for unmet IPv4 requests

["Md. Abdul Awal" <awal.ece@gmail.com>]

I support this proposal.

Since the waiting list is already too big (still growing) and there's no actual progress in terms of address allocation to the member organization from the waiting list, there's no reasonably strong point of keeping the list active.

BR//Awal

On 22/1/19 6:15 AM, Bertrand Cherrier wrote:

Dear SIG members,

The proposal "prop-129-v001: Abolish Waiting list for unmet IPv4
requests" has been sent to the Policy SIG for review.

It will be presented at the Open Policy Meeting at APNIC 47 in
Daejeon, South Korea on Wednesday, 27 February 2019.

We invite you to review and comment on the proposal on the mailing list
before the meeting.

The comment period on the mailing list before an APNIC meeting is an
important part of the policy development process. We encourage you to
express your views on the proposal:

• Do you support or oppose this proposal?
• Does this proposal solve a problem you are experiencing? If so, tell the community about your situation.
• Do you see any disadvantages in this proposal?
• Is there anything in the proposal that is not clear?
• What changes could be made to this proposal to make it more effective?

Information about this proposal is available at:

 http://www.apnic.net/policy/proposals/prop-129

Regards

Sumon, Bertrand, Ching-Heng
APNIC Policy SIG Chairs

---

prop-129-v001: Abolish Waiting list for unmet IPv4 requests

---

Proposers: Aftab Siddiqui
aftab.siddiqui@gmail.com

1. Problem Statement

The current APNIC IPv4 Policy allows each APNIC account holder to receive
up to a /22 from the IPv4 Recovered Pool after they have received a /22
from
the final /8 pool (103/8). However, the Recovered Pool may not always have
enough resources for delegation, therefore a waiting list was created. The
position of a Member on the waiting list is strictly determined by the date
and time that the Member’s completed request received by APNIC. At the time
of writing, there are 658 members in the waiting list. In 2018, APNIC
received 10 x /24 and 1 x /23 (equal to 3 x /22) from IANA recovered pool.
In the same year, more than 400 members were added to the waiting list
where the majority were requesting for /22. IANA recovered address
delegations
are shrinking to a level where it is impossible to provide IPv4
resources to
current 658 members in the waiting list.

2. Objective of policy change

The objective is to remove the waiting list as the IANA or APNIC
recovered address
space is not enough. All the members in the waiting list already have a
minimum of
/22 address space from last /8 (103/8) address block. Whatever is
recovered by IANA
or by APNIC should be left aside to new members ONLY.

3. Situation in other regions

Please correct if otherwise
ARIN - returned and/or recovered address space is added to the ARIN's
free pool
RIPE NCC - returned and/or recovered address space is added to the RIPE
NCC’s free pool
LACNIC - returned and/or recovered address space is added to reserve block
AFRINIC - No Clear

4. Proposed policy solution

Abolish the current waiting list and once the APNIC receives IPv4
recovered address
space from IANA or recovered by themselves (through closures or returns
etc) then
it should be treated under the same policy as last /8 (103/8).

A waiting list will be created once APNIC runs out of resources in last
/8 and same
last /8 allocation policy will be applied to the waiting list.

5. Advantages / Disadvantages

Advantages:
Removing an unnecessary waiting list and able to utilize the recovered
address pool
as part of available IPv4 resources or last /8.

It will also encourage the waiting list members to implement IPv6.

Disadvantages:
No disadvantages.

6. Impact on resource holders

No impact on existing resource holders.

7. References

*              sig-policy:  APNIC SIG on resource management policy           *
_______________________________________________
sig-policy mailing list
sig-policy@lists.apnic.net
https://mailman.apnic.net/mailman/listinfo/sig-policy

Attachment: signature.asc
Description: OpenPGP digital signature