Hi Guangliang,

Thank you for your question.

2017-02-21 15:17 GMT+09:00 Guangliang Pan <[email protected]>:

> From implementation point of view, I have a question about your proposal.
>
> If each new account holder will be given priority in the waiting list, do you 
> mean new account holders will have their whole /21 on the waiting list ahead 
> of those existing account holders who are waiting for their second /22?

Yes, current policy text intends that.

I considered to add some steps such that first application
will be up to /22 and so on, but it will make this policy complex.


Yours Sincerely,
---
Tomohiro Fujisaki


2017-02-21 15:17 GMT+09:00 Guangliang Pan <[email protected]>:
> Dear Tomohiro,
>
> From implementation point of view, I have a question about your proposal.
>
> If each new account holder will be given priority in the waiting list, do you 
> mean new account holders will have their whole /21 on the waiting list ahead 
> of those existing account holders who are waiting for their second /22?
>
> Kind regards,
>
> Guangliang Pan (Benny)
> Registration Services Manager, APNIC
> Email: [email protected]
> SIP: [email protected]
> Phone: +61 7 3858 3188
> http://www.apnic.net
> -----------------------------------------------------------------------------
> * You can now call APNIC Helpdesk for free using Skype. For more information
> visit: www.apnic.net/helpdesk
>
>
>
> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]] On Behalf Of ????
> Sent: Wednesday, 15 February 2017 9:48 PM
> To: Sumon Ahmed Sabir
> Cc: [email protected]
> Subject: Re: [sig-policy] Revised version of Prop-117 (Prop-117-v002)
>
> Dear policy sig colleagues,
>
> I got some comments to prop-117-v001, and modified that as follows.
>
> - changed maximum distribution size after exhaustion equal to current size
> - clean up the text
>
> I would appreciate it if you could give any comments.
>
> Yours Sincerely,
> ---
> Tomohiro Fujisaki
>
>
> 2017-02-15 19:41 GMT+09:00 Sumon Ahmed Sabir <[email protected]>:
>>
>> Dear SIG Members,
>>
>> Tomohiro Fujisaki has submitted a revised version of Prop-117 (
>> Prop-117-v002) after getting some feedback from the community.
>>
>> Please review and  share your thoughts if you have any comments,
>> suggestions on the proposal. This proposal along with three other
>> proposals will be discussed in APNIC43 Policy SIG meeting.
>>
>> Please also find all other proposals for APNIC43 Policy SIG here:
>>
>> https://www.apnic.net/community/policy/proposals/
>>
>>
>>
>> Regards,
>>
>> Masato, Sumon
>>
>>
>>
>> -------------------------------------------------------
>>
>> prop-117-v002: Returned IPv4 address management and Final /8
>> exhaustion
>>
>> -------------------------------------------------------
>>
>> Proposer:       Tomohiro Fujisaki
>>                 [email protected]
>>
>>
>> 1. Problem statement
>> --------------------
>>
>> APNIC currently makes delegations from two IPv4 pools. These are the
>> 103/8 (Final /8) pool and the non-103/8 IPv4 Recovered pool.
>>
>> With current policy, all returned address space, including 103/8
>> blocks, will be merged into the IPv4 Recovered pool.
>>
>> If a 103/8 block is returned, it is placed in the IPv4 Recovered pool
>> and re-distributed as returned space. Some organisations may receive
>> duplicate blocks from 103/8: one under the final /8 policy, the other
>> under the returned pool policy.
>>
>> Current APNIC Policy requires account holders to receive address space
>> from the 103/8 (Final /8) pool before they can apply for address space
>> from the Recovered pool.
>>
>> APNIC currently manages a Recovered Pool Waiting List for approved
>> requests that cannot be met from the IPv4 Recovered pool.
>>
>>
>> 2. Objective of policy change
>> -----------------------------
>>
>> To simplify the address pool management and to provide guidance for
>> 103/8 pool exhaustion.
>>
>>
>> 3. Situation in other regions
>> -----------------------------
>>
>> None.
>>
>>
>> 4. Proposed policy solution
>> ---------------------------
>>
>> Handling reurned address:
>>   - Recovered 103/8 space will be placed in the 103/8 (Final /8) pool.
>>   - Recovered non-103/8 space will be placed in the IPv4 Recovered pool.
>>
>> Guidance for 103/8 pool exhaustion:
>>   - The first time an approved request cannot be fulfilled from the 103/8
>>     pool, Final /8 delegations will end.
>>   - APNIC will begin to manage only one (Recovered) IPv4 pool containing
>>     any residual 103/8 space and all future returns, including 103/8
>> returns.
>>   - Each new account holder can receive up to a /21 from the IPv4
>>     Recovered pool.
>>   - Existing account holders who have not yet received the maximum /21
>>     from the two pools may continue to apply for space from the Recovered
>>     pool until they have received a maximum /21 from the two pools.
>>   - A waiting list will be created if approved requests cannot be
>>     fulfilled. Each new account holder will be given priority in the
>>     waiting list.
>>
>>
>> 5. Advantages / Disadvantages
>> -----------------------------
>>
>> Advantages:
>>
>>   - Simplifying management of remaining IPv4 address pools.
>>
>> Disadvantages:
>>
>> None.
>>
>>
>> 6. Impact on resource holders
>> ------------------------------
>>
>> No impact to resource holders.
>>
>>
>> 7. References
>> -------------
>>
>> prop-117-v2.txt
>> Displaying prop-117-v2.txt.
>>
>> *              sig-policy:  APNIC SIG on resource management policy
>> *
>> _______________________________________________
>> sig-policy mailing list
>> [email protected]
>> https://mailman.apnic.net/mailman/listinfo/sig-policy
> *              sig-policy:  APNIC SIG on resource management policy           
> *
> _______________________________________________
> sig-policy mailing list
> [email protected]
> https://mailman.apnic.net/mailman/listinfo/sig-policy
*              sig-policy:  APNIC SIG on resource management policy           *
_______________________________________________
sig-policy mailing list
[email protected]
https://mailman.apnic.net/mailman/listinfo/sig-policy

Reply via email to