My reads to the data shows exact needs for the policy.So don't blame data.On Wed, Aug 23, 2017 at 16:03 Aftab Siddiqui <aftab.siddiqui at gmail dot com> wrote:I don't think George's data can leads your conclusion.If the data from APNIC Sec can't help you to make up your mind then there is nothing I can do. The information was good enough for me.On Wed, Aug 23, 2017 at 15:35 Aftab Siddiqui <aftab.siddiqui at gmail dot com> wrote:Thanks George for the details.So this policy is trying to solve the problems which don't exist.On Wed, 23 Aug 2017 at 12:28 George Kuo <george at apnic dot net> wrote:Hi Aftab,
Thanks for your patience. I now have more information for you.
Total number of IPv4 market transfers that did not get completed in the
last 12 months is 97.
Below is the breakdown of reasons:
Fraud: 4
Recipient could not demonstrate needs: 1
Recipient did not accept transfer: 6
Requests corrected as M&A transfer: 23
No response from member: 30
Member requested to cancel transfer: 33
As far as administration of these requests is concerned, it's just part
of hostmasters routines required by the APNIC policy.
George
On 18/8/17 6:48 pm, George Kuo wrote:
> Hi Aftab,
>
> For 2017, the secretariat has processed 158 market transfers as of 15
> August. So, this is roughly about 5 transfer requests a week.
> On average, it takes about 4-5 responses from APNIC hostmasters to
> complete a transfer request. We have a procedure to respond to a
> correspondence within two working days.
>
> We are getting the rest of the answers for you. I'll come back to you as
> soon as I have the information.
>
> thanks,
>
> George
>
>
> On 18/8/17 3:29 pm, Aftab Siddiqui wrote:
>> Dear APNIC Sec,
>>
>> Can you share some stats:
>>
>> - How many transfers request denied in last 12 months?
>> - How many requests were denied just because of bad documentation?
>> - How many transfer request you are receiving every week?
>> - How long does it take to process a transfer request?
>> - Does it create any administrative burden?
>>
>> On Wed, 9 Aug 2017 at 16:14 chku <chku at twnic dot net dot tw
>> <mailto:chku at twnic dot net dot tw>> wrote:
>>
>> Dear SIG members
>>
>> The proposal "prop-118: No need policy in APNIC region" was
>> discussed at
>> APNIC 43 Policy SIG, but did not reach consensus.
>>
>> It will be presented at the Open Policy Meeting at APNIC 44 which
>> will
>> be held in Taichung, Taiwan on Wednesday and Thursday, 14 & 15
>> September
>> 2017.
>>
>> Information about the proposal is available from:
>>
>> http://www.apnic.net/policy/proposals/prop-118
>>
>> You are encouraged to express your views on the proposal:
>>
>> - Do you support or oppose the proposal?
>> - 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?
>>
>> Please find the text of the proposal below.
>>
>> Kind Regards,
>>
>> Sumon, Bertrand, Ching-Heng
>> APNIC Policy SIG Chairs
>>
>>
>> -------------------------------------------------------
>>
>> prop-118-v001: No need policy in APNIC region
>>
>> -------------------------------------------------------
>>
>> Proposer: David Hilario
>> d.hilario at laruscloudservice dot net
>> <mailto:d.hilario at laruscloudservice dot net>
>>
>>
>> 1. Problem statement
>> -------------------------------------------------------
>>
>> Whenever a transfer of IPv4 is taking place within the APNIC
>> region, the
>> recipient needs to demonstrate the "need" for the IPv4 space they
>> intend
>> to transfer.
>>
>> Companies transferring IPv4 space to their pool do this in ordcer to
>> enable further growth in their network, since the space is not coming
>> from the free public pool, regular policies that are intended to
>> protect
>> the limited pool of IPv4 space can be removed in transfers.
>>
>>
>> 2. Objective of policy change
>> -------------------------------------------------------
>>
>> Simplify transfer of IPv4 space between resource holders.
>> Ease some administration on APNIC staff.
>>
>>
>> 3. Situation in other regions
>> -------------------------------------------------------
>>
>> RIPE region has an all around no need policy in IPv4, even for first
>> allocation, transfers do not require the recipient to demonstrate
>> their
>> intended use of the resources .
>>
>> ARIN, need base for both transfers and resources issued by ARIN.
>>
>> AFRINIC, need based policy on transfers (not active yet) and resource
>> request from AFRINIC based on needs.
>>
>> LACNIC, no transfers, need based request.
>>
>> Out of all these RIR, only ARIN and RIPE NCC have inter-RIR transfer
>> policies, ARIN has made clear in the past that the "no need" policy
>> from the RIPE region would break inter-RIR transfers from ARIN to
>> RIPE
>> region.
>>
>>
>> 4. Proposed policy solution
>> -------------------------------------------------------
>>
>> Simply copy the RIPE policy to solve the ARIN transfer
>> incompatibility:
>>
>> - APNIC shall accept all transfers of Internet number resources
>> to its
>> service region, provided that they comply with the policies
>> relating
>> to transfers within its service region.
>>
>> - For transfers from RIR regions that require the receiving
>> region to
>> have needs-based policies, recipients must provide a plan to the
>> APNIC for the use of at least 50% of the transferred resources
>> within
>> 5 years.
>>
>> source:
>> https://www.ripe.net/publications/docs/ripe-644
>>
>>
>> 5. Advantages / Disadvantages
>> -------------------------------------------------------
>>
>> Advantages:
>>
>> - Harmonisation with RIPE region.
>> - Makes transfer simpler and smoother within APNIC and between APNIC
>> and RIPE.
>> - maintains a compatibility with ARIN.
>> - Removes the uncertainty that a transfer may be rejected based on
>> potentially badly documented needs.
>> - Lowers the overall administrative burden on APNIC staff.
>>
>> Disadvantages:
>>
>> none.
>>
>>
>> 6. Impact on resource holders
>> -------------------------------------------------------
>> None
>>
>>
>> 7. References
>> -------------------------------------------------------
>>
>>
>>
>>
>> _______________________________________________
>> Sig-policy-chair mailing list
>> Sig-policy-chair at apnic dot net <mailto:Sig-policy-chair at apnic dot net>
>> https://mailman.apnic.net/mailman/listinfo/sig-policy-chair
>> * sig-policy: APNIC SIG on resource management policy
>> *
>> _______________________________________________
>> sig-policy mailing list
>> sig-policy at lists dot apnic dot net <mailto:sig-policy at lists dot apnic dot net>
>> https://mailman.apnic.net/mailman/listinfo/sig-policy
>>
>> --
>> Best Wishes,
>>
>> Aftab A. Siddiqui
>>
>>
>> * sig-policy: APNIC SIG on resource management
>> policy *
>> _______________________________________________
>> sig-policy mailing list
>> sig-policy at lists dot apnic dot net
>> https://mailman.apnic.net/mailman/listinfo/sig-policy
>>
--* sig-policy: APNIC SIG on resource management policy *Best Wishes,Aftab A. Siddiqui
_______________________________________________
sig-policy mailing list
sig-policy at lists dot apnic dot net
https://mailman.apnic.net/mailman/listinfo/sig-policy----
Kind regards.
Lu--Best Wishes,Aftab A. Siddiqui----
Kind regards.
Lu