​I support this proposal but not all of the view.
The point:
The last APNIC 103/8 block is a brand new came from IANA, unused IPv4 block, 
and it is never used by other user on the Internet from other RIR.
The recovered pool IP block is used by other user from other RIR may be.
If the recovered pool IP will assign to the new member, would it have some 
problem when use it ?

Best Regards,
Ernest Tse









On Tue, 22/01/2019 08.15, Bertrand Cherrier <b.cherr...@micrologic.nc> 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.siddi...@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


*              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

Reply via email to