Dear David, The APNIC Secretariat is reviewing the policy proposals under discussion and seeks clarification to better understand the intention of prop-118-v001: No need policy in APNIC region.
APNIC remains neutral and objective about the outcome of this discussion and only requires clarification to ensure correct implementation, should the proposal reach consensus. These questions refer to the first bullet point in Section 4 'Proposed policy solution'. - In that bullet point; "to its service region" seems to refer to recipients of inter-region transfers. Can you be specific about which transfers this proposal affects? Do you intend for the policy to also apply to transfers within the regional, including those between APNIC and NIR account holders? - That bullet point requires transfers to "comply with the policies relating to transfers within its service region". Which region are you referring to? The APNIC region, or the counterpart region in an inter-RIR transfer? I think I understand your intention, but the current text seems to require transfers to comply with existing policy. We would appreciate your clarification. Regards, Adam _______________________________________________________ Adam Gosling Senior Internet Policy Analyst, APNIC e: [email protected] p: +61 7 3858 3142 m: +61 421 456 243 www.apnic.net _______________________________________________________ Join the conversation: https://blog.apnic.net/ _______________________________________________________ On 24/8/17, 13:57, "[email protected] on behalf of David Hilario" <[email protected] on behalf of [email protected]> wrote: Hi, On 23 August 2017 at 10:34, Aftab Siddiqui <[email protected]> wrote: > Thanks George for the details. > > So this policy is trying to solve the problems which don't exist. > The policy is not trying to fix a "problem", it is trying to simplify things and lighten the administrative burden in the process. We tend to amass a lot of procedures and policies that stick around simply because "that's how we always have done it". Over time things become just a bit anachronistic. Need base was intended for the purpose of slowing the exhaustion of the global IP pool, while we prepare for the replacement protocol... and somehow we submitted that one to stricter distribution from day one and it is currently still trying to recover. Need demonstration was never intended to prevent IPv4 holders from exchanging IPs between each other, keeping the need based purpose on transfers is actually difficult to justify. Prevent speculators and hoarders? Organisations with large pockets can do this already, need base can justify almost any sizes in the world of VPS. We are only restricting smaller organisations willing to acquire resources in order try to have enough IPv4 space to cover their future needs based on what they can afford today. While larger organisations have no problem forking out large amount of money and can justify any sizes really. > > 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 Good news they that they were caught. >> Recipient could not demonstrate needs: 1 Interesting number. Was it a "could not demonstrate any need?", or "a specific need for a specific transfer size?" I would guess it is the second option, specific need for specific transfer size. >> Recipient did not accept transfer: 6 That category is odd, I know APNIC cannot give details of individual case, but why would a recipient be rejecting a transfer that they somehow initiated to begin with. >> Requests corrected as M&A transfer: 23 Removing the need base in transfer would even simplify those, you can do an M&A provide lots of sensitive confidential information to a third party, or simply do a transfer of the resources. Anyone who has been involved in an M&A would know that it involves an enormous amount of work and lots of extremely sensitive information that often is not really appropriate to share with any external parties. >> No response from member: 30 >> Member requested to cancel transfer: 33 >> You still have 63 cancelled transfers for whatever reason, if that is due to the administrative burden put on the offering and receiving party, it is then a big waste of time for all involved, LIRs and RIR. If the "no need base" can help to lower the amount of cases that are simply given up, then the policy would have had an impact. You also have non quantifiables, such as "Requested pre-approval evaluation", got /19 pre-approved but was aiming for /18 or higher. So the Data is not really demonstrating the futility of the proposal, just showing there are issues with the current system and some tweaking of the current policies is needed. >> 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 David Hilario IP Manager Larus Cloud Service Limited p: +852 29888918 m: +359 89 764 1784 f: +852 29888068 a: Flat B5, 11/F, TML Tower, No.3 Hoi Shing Road, Tsuen Wan, HKSAR w: laruscloudservice.net e: [email protected] * 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
