Re: [sig-policy] sig-policy Digest, Vol 160, Issue 27--support prop-116-v005 that 103/8 can't be transfered in 2 years

  • To: xswdesert <xswdesert@163.com>
  • Subject: Re: [sig-policy] sig-policy Digest, Vol 160, Issue 27--support prop-116-v005 that 103/8 can't be transfered in 2 years
  • From: Ernest Tse <ernest.tse@pacswitch.com>
  • Date: Thu, 12 Oct 2017 10:34:00 +0000 (UTC)
  • Cc: sig-policy@lists.apnic.net
  • Delivered-to: sig-policy@clove.apnic.net
  • Dkim-signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=sendgrid.net; h=from:to:cc:reply-to:in-reply-to:references:subject:mime-version:content-type; s=smtpapi; bh=YEr702MXY4oCr7VgdnF3+dKbvME=; b=GHvVcnWfqDF1hGS6WX 6B6eqQemysODZG2RU4+YgPB0pIo2ipUHxtO7lKH0xxIlcADUYemA3rdY/nYPeFjY RkDSb1YDIPFwYKtdWsv65dSQAln2D8TLoe/qSLAwdaOi8ds7R+1A4GvCgHvGSI6x k5hUUz2p54Y3H4OlFc2WmcFI8=
  • Importance: Normal
  • In-reply-to: <7af5b9f5.c12b.15f1014dfa0.Coremail.xswdesert@163.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: <7af5b9f5.c12b.15f1014dfa0.Coremail.xswdesert@163.com>
  • Reply-to: Ernest Tse <ernest.tse@pacswitch.com>

    • Dear Sirs,


      I would also suggest that 2 years is a reasonable time frame for transfer.

      Many members are still don`t know this limit will apply to their account soon.



      Best Regards,

      Ernest Tse



      On Thu, 12/10/2017 18.15, xswdesert <xswdesert@163.com> wrote:
      Dear community,
      We support the previous version that 103/8 can't be transfered in 2 years. 2 years limit is reasonable.
      Changing the time limit from 2 years to 5 years was a big change to the proposal 116. Many community members didn't know the change if they didn't attent this meeting. After this big change, We didn't understand why not return it to the mailing list to discusse before gauge consensus onsite.
      Regards,


      发件人: sig-policy-bounces@lists.apnic.net [mailto:sig-policy-bounces@lists.
      apnic.net] 代表 sig-policy-request@lists.apnic.net
      发送时间: 2017年9月18日 15:45
      收件人: sig-policy@lists.apnic.net
      主题: sig-policy Digest, Vol 160, Issue 27

      Send sig-policy mailing list submissions to
              sig-policy@lists.apnic.net

      To subscribe or unsubscribe via the World Wide Web, visit
              https://mailman.apnic.net/mailman/listinfo/sig-policy
      or, via email, send a message with subject or body 'help' to
              sig-policy-request@lists.apnic.net

      You can reach the person managing the list at
              sig-policy-owner@lists.apnic.net

      When replying, please edit your Subject line so it is more specific than
      "Re: Contents of sig-policy digest..."


      Today's Topics:

         1.  Moratorium on 103/8 transfers (Secretariat)
         2.  Final Comment Period for prop-116: Prohibit to   transfer IPv4
            add       resses in the final /8 block (chku)
         3.  prop-118: No need policy in APNIC region returned to     author
            (chku)


      ----------------------------------------------------------------------

      Message: 1
      Date: Mon, 18 Sep 2017 14:38:07 +1000
      From: Secretariat <Secretariat@apnic.net>
      To: <sig-policy@lists.apnic.net>
      Subject: [sig-policy] Moratorium on 103/8 transfers
      Message-ID: <85f26a94-19b2-1071-3cd5-ac2977491940@apnic.net>
      Content-Type: text/plain; charset="utf-8"; format=flowed

      ________________________________________________________________________

      Moratorium on 103/8 transfers
      ________________________________________________________________________


      At APNIC 44 in Taichung last week, policy proposal prop-116 ?Prohibit to
      transfer IPv4 addresses in the final /8 block? reached consensus.

           https://www.apnic.net/wp-content/uploads/2017/09/prop-116-v006.txt

      At the APNIC Member Meeting on Thursday, 14 September, the APNIC Executive
      Council (EC) placed an immediate moratorium on all transfers from the 103/8
      block.

      This moratorium is now in place and any transfer request from 103/8 received
      by APNIC on or after 14 September 2017 will be deferred until such time that
      the moratorium is lifted by the APNIC EC.

      When prop-116 completes the remaining steps in the Policy Development
      Process, the APNIC Secretariat will advise the EC and community. The APNIC
      EC intends to lift the moratorium once the proposal either fails, or is
      implemented.

      ________________________________________________________________________

      APNIC Secretariat???????????????????????????????? secretariat@apnic.net Asia
      Pacific Network Information Centre (APNIC)?? Tel:? 61 7 3858 3100 PO Box
      3646 South Brisbane, QLD 4101 Australia??? Fax:? 61 7 3858 3199
      6 Cordelia Street, South Brisbane, QLD??????????? http://www.apnic.net
      ________________________________________________________________________


      ------------------------------

      Message: 2
      Date: Mon, 18 Sep 2017 15:43:32 +0800 (CST)
      From: "chku" <chku@twnic.net.tw>
      To: "sig-policy" <sig-policy@apnic.net>
      Subject: [sig-policy] Final Comment Period for prop-116: Prohibit to
              transfer IPv4 add       resses in the final /8 block
      Message-ID: <1505720612.174740.chku@twnic.net.tw>
      Content-Type: text/plain; charset="utf-8"

      Dear colleagues

      A revised version "prop-116-v006: Prohibit to transfer IPv4 addresses in the
      final /8 block" reached consensus at the APNIC 44 Policy SIG and then later
      at the APNIC Member Meeting (AMM).

      Synopsis:
      ---------
      The proposed policy solution reaching consensus is:

      Prohibit transfer IPv4 addresses under final /8 address block (103/8) which
      have not passed five years after its allocation/assignment. If the address
      block allocated to a LIR in five years is not needed any more, it must
      return to APNIC to allocate to another organization using final
      /8 policy. This five years requirement will apply both market and M&A
      transfers.

      This proposal will now move to the next step in the APNIC Policy Development
      Process and is being returned to the Policy SIG mailing list for the final
      Comment Period.

         - Deadline for comments:  23:59 (UTC +10) Wednesday, 18 October 2017

      Proposal details, including the full text of the proposal, history, and
      links to previous versions are available at:

          https://www.apnic.net/community/policy/proposals/prop-116/

      Regards

      Sumon, Bertrand, Ching-Heng
      Policy SIG Chairs


      -------------------------------------------------------

      prop-116-v006: Prohibit to transfer IPv4 addresses in the final /8 block

      -------------------------------------------------------

      Proposer:       Tomohiro Fujisaki
                      fujisaki@syce.net


      1. Problem statement
      --------------------

      There are a lot of transfers of IPv4 address blocks from 103/8 happening,
      both within the APNIC region and among RIRs.

      Then number of transfers from 103/8 block are 352, which is about 14% of the
      total number of transfers as of 10 Septermber 2017.
      This is the highest number of transfers in all APNIC managed /8s.

      And based on the information provided by APNIC Secretariat, number of
      transfers from the 103/8 block are increasing year by year.

      Updated by APNIC Secretariat on 27 January 2017:

      1) M&A transfers containing 103/8 space

      +------+-----------+-----------+-
      |      |   Total   | Number of |
      | Year | Transfers |   /24s    |
      +------+-----------+-----------+-
      | 2011 |         3 |         12 |
      | 2012 |        10 |         46 |
      | 2013 |        18 |         66 |
      | 2014 |       126 |        498 |
      | 2015 |       147 |        573 |
      | 2016 |        63 |        239 |
      | 2017 |        45 |        178 |
      +------+-----------+------------+-

      2) Market transfers containing 103/8 space

      +------+-----------+-----------+
      |      |   Total   | Number of |
      | Year | Transfers |   /24s    |
      +------+-----------+-----------+
      | 2011 |         2 |         2 |
      | 2012 |        21 |        68 |
      | 2013 |        16 |        61 |
      | 2014 |        25 |        95 |
      | 2015 |        67 |       266 |
      | 2016 |       103 |       394 |
      | 2017 |        70 |       288 |
      +------+-----------+-----------+

      And also, transfers from the 103/8 block include:
        - Take place within 1 year of distribution, or
        - Multiple blocks to a single organization in case of beyond 1 year.

      Further, there is a case where a single organization have received 12 blocks
      transfers from 103 range.

      see:  https://www.apnic.net/transfer-resources/transfer-logs

      From these figures, it is quite likely that substantial number of 103/8
      blocks are being used for transfer purpose.

      This conflicts with the concept of distribution of 103/8 block (prop-062),
      which is intended to accommodate minimum IPv4 address blocks for new comers.

      prop-062: Use of final /8
        https://www.apnic.net/policy/proposals/prop-062


      2. Objective of policy change
      -----------------------------

      When stated problem is solved, distribution from 103/8 block will be
      consistent with its original purpose, for distribution for new entrants to
      the industry. Without the policy change, substantial portion of 103/8 blocks
      will be consumed for transfer purpose.


      3. Situation in other regions
      -----------------------------
      "RIPE Resource Transfer Policies" says:

         2.2 Transfer Restrictions

          Scarce resources, which are understood as those resources that are
          allocated or assigned by the RIPE NCC on a restricted basis (such as
          IPv4 or 16-bit ASNs), cannot be transferred for 24 months from the
          date the resource was received by the resource holder. This
          restriction also applies if the resource was received due to a change
          in the organisation??s business (such as a merger or acquisition).


      4. Proposed policy solution
      ---------------------------

      Prohibit transfer IPv4 addresses under final /8 address block (103/8) which
      have not passed five years after its allocation/assignment. If the address
      block allocated to a LIR in five years is not needed any more, it must
      return to APNIC to allocate to another organization using final /8 policy.
      This five years requirement will apply both market and M&A transfers.


      5. Advantages / Disadvantages
      -----------------------------

      Advantages:
        - It makes 103/8 blocks available according to the original purpose,
          as distribution for new entrants (rather than being consumed for
          transfer purpose)

        - IPv4 addresses under final /8 are not transferred to outside APNIC.

        - By prohibiting transfer, them, it is possible to keep one /22 for
          each LIRs state, which is fair for all LIRs.

      Disadvantages:

      None.


      6. Impact on resource holders
      ------------------------------

        - LIRs cannot transfer address blocks under 103/8. No big impact while
          they use it.

        - Organizations which needs to receive transferred IPv4 can continue
          to do so, outside 103/8 blocks (which should be made available for
          new entrants)


      7. References
      -------------
      RIPE Resource Transfer Policies
      http://www.ripe.net/publications/docs/transfer-policies
      -------------- next part --------------
      An embedded and charset-unspecified text was scrubbed...
      Name: 00.txt
      URL:
      < http://mailman.apnic.net/mailing-lists/sig-policy/attachments/20170918/0e64
      5384/attachment.txt
      >

      ------------------------------

      Message: 3
      Date: Mon, 18 Sep 2017 15:44:52 +0800 (CST)
      From: "chku" <chku@twnic.net.tw>
      To: "sig-policy" <sig-policy@apnic.net>
      Subject: [sig-policy] prop-118: No need policy in APNIC region
              returned to     author
      Message-ID: <1505720692.175013.chku@twnic.net.tw>
      Content-Type: text/plain; charset="big5"

      Dear colleagues

      Version 1 of prop-118: No need policy in APNIC region, did not reach
      consensus at the APNIC 44 Open Policy Meeting.

      The Policy SIG Chairs returned the proposal to the author for further
      consideration and invited him to submit an amended version based on the
      community's feedback.

      Proposal details, including the full text of the proposal, history, and
      links to previous versions are available at:

          https://www.apnic.net/community/policy/proposals/prop-118/


      Regards

      Sumon, Bertrand, Ching-Heng
      Policy SIG Chairs


      -------------------------------------------------------

      prop-118-v001: No need policy in APNIC region

      -------------------------------------------------------

      Proposer:       David Hilario
                      d.hilario@laruscloudservice.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
      -------------------------------------------------------
      -------------- next part --------------
      An embedded and charset-unspecified text was scrubbed...
      Name: 00.txt
      URL:
      < http://mailman.apnic.net/mailing-lists/sig-policy/attachments/20170918/11b9
      df79/attachment.txt
      >

      ------------------------------

      _______________________________________________
      sig-policy mailing list
      sig-policy@lists.apnic.net
      https://mailman.apnic.net/mailman/listinfo/sig-policy

      End of sig-policy Digest, Vol 160, Issue 27
      *******************************************




      * sig-policy: APNIC SIG on resource management policy *
      _______________________________________________
      sig-policy mailing list
      sig-policy@lists.apnic.net
      https://mailman.apnic.net/mailman/listinfo/sig-policy