[sig-policy] transfer discussions

  • To: sig-policy at apnic dot net
  • Subject: [sig-policy] transfer discussions
  • From: Randy Bush <randy at psg dot com>
  • Date: Wed, 25 Feb 2009 11:42:16 +0800
  • Delivered-to: sig-policy at mailman dot apnic dot net
  • 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: <http://mailman.apnic.net/mailman/listinfo/sig-policy>, <mailto:sig-policy-request@lists.apnic.net?subject=subscribe>
  • List-unsubscribe: <http://mailman.apnic.net/mailman/listinfo/sig-policy>, <mailto:sig-policy-request@lists.apnic.net?subject=unsubscribe>
  • User-agent: SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (Gojō) APEL/10.7 Emacs/22.3 (i386-apple-darwin9.6.0) MULE/5.0 (SAKAKI)
    • 
      Below is a summary of discussions on the transfer proposal to date. As
      discussed previously on this mailing list, we will handle the transfer
      discussion as "features for decision" as opposed to "competing
      proposals". Therefore, we are not posting summaries on individual
      transfer proposals, but on the main points of discussion on transfer
      proposals in general.
      
      We strongly encourage you to continue discussions on the mailing list
      before the Policy SIG this Thursday, 26 February 2009.
      
      Regards,
      Randy and Jian
      
      
      Transfer proposals: main points of discussion
      ---------------------------------------------
      
           - Minimum size, /24 or then current size
           - Recipient to justify use
           - Inter-RIR transfer
           - NIR-APNIC transfer
           - Inter-NIR transfer
           - Seller must be full member of APNIC
           - Seller may/may not get more space for some time period
           - APNIC to maintain a public log of all transfers
      
      
      Discussion statistics
      ---------------------
      
      Number of posts since APNIC 26:                   71
      
      Number of people participating in discussions:    10
      
      
      Summary of discussion on key features of transfer proposals
      -----------------------------------------------------------
      
          1. Minimum size: /24 or minimum allocation size in place at time
             transfers are implemented:
      
              - There's a possibilty that the APNIC minimum allocation will
                become smaller as we get closer to the depletion of the IANA
                and APNIC unallocated IPv4 pools.
      
               - In favour of minimum transfer size of /24:
      
                  - Not likely to be practical to make the prefix shorter than 
                    a /24.
                  - /24 is a reasonable size to ensure the smooth transfer of
                    addresses.
                  - Choice of route size isn't governed by allocation or
                    transfer sizes.
      
               - In favour of minimum allocation/assignment size:
      
                  - Routing table growth is a serious problem for ISPs.
                  - It may not match routing reality, but it's better to
                    start with a shorter prefix first and make it longer if
                    needed.
                  - If the community changes its mind about the minimum
                    transfer size, it's not possible to make the minimum
                    transfer size shorter if you start with a longer prefix.
                  - If you define it as a /24, prefixes will be fragmented
                    that far for sure, including prefixes which are currently
                    aggregated.
      
      
          2. Recipient to justify need for addresses:
      
               - In favour of justifying use:
      
                  - It doesn't make sense to stop justification just because
                    the APNIC pool runs out.
                  - It will prevent hoarding/speculation.
      
               - In favour of not justifying need for addresses:
      
                  - We can't expect the address management policy framework to
                    remain the same after the IPv4 pool runs out.
                  - It is contrary to transfer goals to restrict transfers.
                    Adding restrictions could lead to even more underground
                    transfers.
                  - It may increase the operational expenses of APNIC and the
                    NIRs. Members don't want to be burdened by additional fees
                    as a result of extra work needed by hostmasters to analyse
                    whether a transfer is justified.
      
      
          3. Inter-RIR transfer
      
               - There's a risk that networks in wealthier regions could strip
                 address space from developing regions.
      
                   - There's an acknowledgement that this could happen within
                     the same region as well.
                   - Such concerns reflect a colonialist perspective.
      
               - Which RIR's policies apply in a transfer if there's a
                 difference in transfer policies in the regions involved?
      
      
          4. NIR-APNIC transfer
      
              - There is a desire by the JPNIC community to include NIRs in
                the transfer policies.
      
      
          5. APNIC to maintain a public log of all transfers
      
               - Documentation would be useful for non-technical people in
                 authenticating a transfer.
      
               - Such a log could help transfer recipients debug routing
                 issues associated with addresses "contaminated" by previous
                 holders who may have spammed, etc.
      
               - It was noted that a public log cannot solve all routability
                 issues.
      
      
          6. To take effect now or on last /8 received
      
               - It was noted that both prop-050 and prop-067, as written,
                 would be implemented as soon as practicable after endorsement.
                 However, it is likely to take a number of months to work out
                 all the implementation implications.
      
               - It was suggested that while organizations can still obtain
                 address resources via the current allocation process, the
                 community shouldn't create demand and support for transfers
                 which could have significant effects on the general
                 community. However, it was further commented that a transfer
                 policy should be adopted soon so procedures can be
                 established and ready at the time they are needed.
      
               - It was suggested that if the implementation of a transfer
                 policy was delayed until around the time of exhaustion, a
                 black market in address transfers would increase.
      
               - If the policy was implemented once IPv4 was exhausted, it was
                 questioned whether "exhausted" meant exhaustion of the APNIC
                 pool before or after the final /8 policy was activated (see
                 http://www.apnic.net/policy/add-manage-policy.html#9.10).
      
               - It was suggested that if APNIC did not have the expertise
                 to develop mechanisms to ensure transfers were fair and
                 trustable, APNIC should:
      
                   - liaise with experts to find appropriate mechanisms
                   - keep the community well informed about work being done
                     using the expertise within their economies, or,
                   - provide an analysis of how transfers can work without
                     taking the above measures
      
              - There was a comment that without detailed information about
                how the proposed policy would be implemented, it wasn't
                possible to support the proposal.
      
                   - In response, there was a comment that the need for many
                     other stakeholders to have time to plan for their response
                     to this situation, and the limited time now available,
                     means that the policy process now needs to be resolved
                     quickly in order to allow others to build upon this
                     framework with their own policies and actions.
      
                  - It was also suggested that APNIC could not be expected to
                     establish what would be considered fair and trustworthy
                     within the constraints of a specific economy's own laws,
                     customs, and governmental frameworks. It was suggested
                     that economy-specific issues should not hamper policy
                     making at the APNIC level.
      
      Of the remaining features to be discussed in Thursday's Policy SIG,
      there has not been any discussion on the mailing list since APNIC 26.
      We'd appreciate some comments on the mailing list, before Thursday, on
      the following issues:
      
          7. Inter-NIR transfer
      
          8. Seller must be a full member of APNIC
      
          9. Seller may/may not get more space for a certain time period