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.siddi...@gmail.com <mailto: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

Attachment: signature.asc
Description: OpenPGP digital signature

*              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