Re: [sig-policy] [Sig-policy] prop-118: No need policy in APNIC region,

    • To: mailman_SIG-policy <sig-policy at apnic dot net>
    • Subject: Re: [sig-policy] [Sig-policy] prop-118: No need policy in APNIC region, to be dis cussed at APNIC 44 Policy SIG
    • From: Adam Gosling <adam at apnic dot net>
    • Date: Fri, 1 Sep 2017 08:09:13 +0000
    • Accept-language: en-AU, en-US
    • Authentication-results: apnic.net; dkim=none (message not signed) header.d=none; apnic.net; dmarc=none action=none header.from=apnic.net;
    • Delivered-to: sig-policy at mailman dot apnic dot net
    • In-reply-to: <CANoO2f4r=ZT=_VJXOG-ARdZiaN0Tbgj7wZQdbvT_Vfq6Z15u3A@mail.gmail.com>
    • List-archive: <http://mailman.apnic.net/mailing-lists/sig-policy/>
    • List-help: <mailto:sig-policy-request@lists.apnic.net?subject=help>
    • List-id: APNIC SIG on resource management policy <sig-policy.lists.apnic.net>
    • List-post: <mailto:sig-policy@lists.apnic.net>
    • List-subscribe: <https://mailman.apnic.net/mailman/listinfo/sig-policy>, <mailto:sig-policy-request@lists.apnic.net?subject=subscribe>
    • List-unsubscribe: <https://mailman.apnic.net/mailman/options/sig-policy>, <mailto:sig-policy-request@lists.apnic.net?subject=unsubscribe>
    • References: <1502259229.62011.chku@twnic.net.tw> <CAK5YLgfjZyT_XJayFCh2o-vhtxaEoutLC4onQyFdnLzHU6A-Xg@mail.gmail.com> <672908de-bb49-b2c4-983c-ddd45dbbab07@apnic.net> <c18042c2-b149-199c-d1cd-aabbeed6e977@apnic.net> <CAK5YLgd=P5+3RSYEWRUNkbTXt0h3YxfSfv1dnAcxe141Mk8wLA@mail.gmail.com> <CANoO2f4r=ZT=_VJXOG-ARdZiaN0Tbgj7wZQdbvT_Vfq6Z15u3A@mail.gmail.com>
    • Spamdiagnosticoutput: 1:0
    • Thread-index: AQHTF+MfZwyT/PzsBE2LrUwK/uwUyaKJzcsAgAfFLwCAAAHLgIABVNIAgA2BdYA=
    • Thread-topic: [sig-policy] [Sig-policy] prop-118: No need policy in APNIC region, to be dis cussed at APNIC 44 Policy SIG
      • 
        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: adam at apnic dot net
        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, "sig-policy-bounces at lists dot apnic dot net on behalf of David Hilario" <sig-policy-bounces at lists dot apnic dot net on behalf of d.hilario at laruscloudservice dot net> wrote:
        
            Hi,
            
            
            On 23 August 2017 at 10:34, 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.
            >
            
            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 <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
            
            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 <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
            >> >>
            >
            > --
            > 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
            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: d.hilario at laruscloudservice dot net
            *              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