Hi Bill,

I will answer as the author.
I chose /16 as a starting point for discussion, at least, because my experience 
as a broker demonstrates a distinction in buyers and sellers around that size.
I suppose we could go by ARIN billing policy which has different definitions, 
but I think a /16 is a medium size.
Most transactions have been at or below this number.
There is a complete record of transfers available at APNIC and ARIN, including 
the sizes of all transferred blocks.
APNIC's list is a little cluttered with quasi-internal transfers to National 
Internet Registries, but is available here:
ftp://ftp.apnic.net/public/transfers/apnic/
ARIN here:
https://www.arin.net/knowledge/statistics/transfers.html

Regards,
Mike Burns

  ----- Original Message ----- 
  From: Bill Darte 
  To: John Springer 
  Cc: [email protected] 
  Sent: Tuesday, April 29, 2014 7:59 AM
  Subject: Re: [arin-ppml] ARIN-prop-204 Removing Needs Test from Small IPv4 
Transfers (fwd)


  Hi John,


  Couple of questions..... could the solution for staff effort be solved more 
directly by modifying the protocol that establishes team testing for each and 
every request through exhaustion?  I wonder about the need for these 
extraordinary measures.


  Is /16 small?  Did you consider a different boundary....say, /20?
  How much of a record do we have for transfer requests yet?  Until exhaustion 
we don't know what the run rate will be or the average size block request.  
Though I believe the that those metrics should mimic pre-exhaustion as I see 
nothing magic affecting network build out and business demands in the pre-post 
time frames.


  So, I neither support, nor oppose this proposal but hope to inform the 
discussion through my questions.


  bd







  On Tue, Apr 29, 2014 at 12:35 AM, John Springer <[email protected]> 
wrote:

    Hi All,

    The following timely policy proposal is presented for your consideration, 
discussion and comment. Will you please comment?

    As always, expressions of support or opposition (and their reasons) are 
given slightly more weight than reasons why you might be in neither condition.

    John Springer


    ARIN-prop-204 Removing Needs Test from Small IPv4 Transfers

    Date: 16 April 2014
    Problem Statement:
    ARIN staff, faced with a surge in near-exhaust allocations and subsequent 
transfer requests and a requirement for team review of these, is spending 
scarce staff time on needs testing of small transfers. This proposal seeks to 
decrease overall ARIN processing time through elimination of that needs test.
    Policy statement:
    Change the language in NRPM 8.3 after Conditions on the recipient of the 
transfer: from "The recipient must demonstrate the need for up to a 24-month 
supply of IP address resources under current ARIN policies and sign an RSA." to 
"For transfers larger than a /16 equivalent, the recipient must demonstrate the 
need for up to a 24-month supply of IP address resources under current ARIN 
policies and sign an RSA."
    Change the language in the third bullet point in NRPM 8.4 after Conditions 
on the recipient of the transfer: from "Recipients within the ARIN region must 
demonstrate the need for up to a 24-month supply of IPv4 address space." to 
"For transfers larger than a /16 equivalent, recipients in the ARIN region must 
demonstrate the need for up to a 24-month supply of IP address resources under 
current ARIN policies and sign an RSA."
    Comments:
    Needs testing has been maintained for transfers largely because the 
community wishes to ensure protection against hoarding and speculation in the 
IPv4 market. This proposal seeks a middle ground between the elimination of 
needs tests for transfers altogether, and the continuance of needs tests for 
every transfer. This should help ARIN staff to reduce transfer processing time, 
since most transfers have been smaller than /16.
    Timetable for implementation: Immediate

    _______________________________________________
    PPML
    You are receiving this message because you are subscribed to
    the ARIN Public Policy Mailing List ([email protected]).
    Unsubscribe or manage your mailing list subscription at:
    http://lists.arin.net/mailman/listinfo/arin-ppml
    Please contact [email protected] if you experience any issues.





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


  _______________________________________________
  PPML
  You are receiving this message because you are subscribed to
  the ARIN Public Policy Mailing List ([email protected]).
  Unsubscribe or manage your mailing list subscription at:
  http://lists.arin.net/mailman/listinfo/arin-ppml
  Please contact [email protected] if you experience any issues.
_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List ([email protected]).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact [email protected] if you experience any issues.

Reply via email to