> > 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 <[email protected]> > 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 <[email protected]> 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 <[email protected] >>> >> <mailto:[email protected]>> 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 >>> >> [email protected] >>> >> <mailto:[email protected]> >>> >> >>> >> >>> >> 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 >>> >> [email protected] <mailto:[email protected]> >>> >> https://mailman.apnic.net/mailman/listinfo/sig-policy-chair >>> >> * sig-policy: APNIC SIG on resource management >>> policy >>> >> * >>> >> _______________________________________________ >>> >> sig-policy mailing list >>> >> [email protected] <mailto:[email protected]> >>> >> 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 >>> >> [email protected] >>> >> 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 >> [email protected] >> https://mailman.apnic.net/mailman/listinfo/sig-policy > > -- > -- > Kind regards. > Lu > > -- Best Wishes, Aftab A. Siddiqui
* sig-policy: APNIC SIG on resource management policy * _______________________________________________ sig-policy mailing list [email protected] https://mailman.apnic.net/mailman/listinfo/sig-policy
