[arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate

[Mike Burns]

I wanted to take a second to provide some clarity on this particular email 
thread to ensure that everyone's expectations are the same. ARIN Staff 
touched base with the Proposal Originator (Mike Burns) and it was confirmed 
by Mike that his intent on sending this to PPML was not to formally submit 
it but to get feedback from the community prior to formally submitting. With 
that in mind, this proposal has not been assigned a Policy Proposal number 
as yet and AC shepherds have not been assigned.




Hi John,

I will send it to policy at arin.net today.

The objections I have noted seem to fall in three categories:

1. That's not the way we have historically dealt with addresses.
2. It could lead to disaggregation
3. Hoarders and speculators will appear and will unfairly manipulate price.

As far as 1, my argument is that the historical method was appropriate for 
free pool allocations, as it provided the necessary constraint for doling 
out valuable resources without a price. The economic concept of the Tragedy 
of the Commons holds that without any constraint, that the resources would 
be overconsumed. In our world, this would mean that people would grab more 
addresses than they could use, unless we constrained them by demonstrated 
need. In a post-exhaust world, price would impose that constraint. Our job 
as stewards is to make policy to ensure accurate Whois, and to end policies 
which provide disincentives for under-utilized addresses to enter the 
market, driving up price. Needs requirements designed to constrain the 
delivery of free pool addresses are no longer required for stewardship, and 
maintaining them for transfers threatens Whois accuracy, whose stewardship 
we maintain.

As far as 2, this danger seems to be manageable, and there haven't been too 
many objections related to this lately. I have argued that the stewards of 
the APNIC region, led by Geoff Huston, considered this problem when deciding 
whether to have needs requirements on transfers, and decided the benefits to 
Whois accuracy outweighed the potential disaggregation problems. This cost 
is borne most by network operators, who presumably can make decisions on 
minimum block size which will allow them to run profitably. Those decisions 
will likely shape the transfer market, so nobody expects there to be much 
value in a /32 netblock, because network operators find this size 
unprofitable to route today. This ability of network operators provides a 
constraint on disaggregation in the transfer market.

And as far as 3, I have argued that speculators provide a value to free 
markets, that most attempts to corner markets fail, that supply uncertainty 
and IPv6 deployment provide a poor environment for speculators. But inasmuch 
as this forum is populated by technical types who are making decisions here 
based on their understanding of, and philosophy of, economics, I have 
decided to take David Farmer's advice and add an anti-speculator, 
anti-hoarder protection in the form of a limit of a /12 equivalent for 
needs-free transfers per 12 month period. If more transfers than that are 
desired, the recipient will have to demonstrate need.

As a whole, then, my policy seeks to recognize that there are transfer 
transactions which provide incentives for buyers and sellers of addresses 
but which transactions may not meed the needs requirements which ARIN 
mandates for transfers. Additionally, I pointed out that network operators, 
in my experience, will route addresses whose Whois record does not reflect 
that the network operator's customer is the registrant. The network 
operator, in my experience, will normally check to make sure that nobody 
else is advertising the addresses, and will solicit from the customer some 
documentary evidence that the customer has the right to the route the 
addresses, and then the network operator will route the addresses.

The net effect of these types of transactions is a lack of trust in the 
Whois table as an accurate source to check for authoritative routing rights. 
My proposal seeks to reduce the harm to Whois accuracy by extending the 
range of allowable transactions, providing additional incentive to have 
transfers reflected accurately by ARIN's updating of Whois to reflect the 
transfer.

As we move into a trading world, which will happen whether or not my 
proposal passes, conflicts over address control are likely to increase, and 
the value of trust in Whois as the routing authority will also increase. 
Rather than sit back and watch Whois decay, I urge ARIN stewards to consider 
making these changes to foster accuracy in Whois.

Regards,
Mike

PS I will change the name to Removing the needs requirement for IPv4 
transfers smaller than a /12 and send it in today.






----- Original Message ----- 
From: "Sweeting, John" <john.sweeting at twcable.com>
To: "Mike Burns" <mike at nationwideinc.com>; <arin-ppml at arin.net>
Sent: Wednesday, May 18, 2011 10:32 AM
Subject: Re: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate


Hello PPML,

I wanted to take a second to provide some clarity on this particular email 
thread to ensure that everyone's expectations are the same. ARIN Staff 
touched base with the Proposal Originator (Mike Burns) and it was confirmed 
by Mike that his intent on sending this to PPML was not to formally submit 
it but to get feedback from the community prior to formally submitting. With 
that in mind, this proposal has not been assigned a Policy Proposal number 
as yet and AC shepherds have not been assigned.

Thanks,
John
AC Chair


On 5/11/11 2:03 PM, "Mike Burns" <mike at nationwideinc.com> wrote:

1. Policy Proposal Name: IPv4 Transfer Policy Change to Keep Whois Accurate

2. Proposal Originator:
      a. Name: Mike Burns
      b. Email: mike at sum.net <mailto:mike at sum.net>
     c. Phone: 1-863-494-7692 x105
      d. Organization: Nationwide Computer Systems

3. Proposal Version: 1

4. Date: May 11th, 2011

5. Proposal type: modify

6. Policy term: permanent

7. Policy statement:

Replace Section 8.3 with

8.3 ARIN will process and record IPv4 address transfer requests.

Conditions on the IPv4 address block:

    - The minimum transfer size is a /24

    - The address block must be in the range of addresses administered
      by ARIN

Conditions on source of the transfer:

    - The source entity must be the current rights holder of the
      IPv4 address resources, and not be involved in any dispute as to
      the status of those resources.

    - The source entity will be ineligible to receive any further IPv4
      address allocations or assignments from ARIN for a period of 12
      months after the transfer, or until the exhaustion of ARIN's
      IPv4 space, whichever occurs first.

      - The source entity must not have received an allocation from ARIN for 
the 12 months prior to the transfer.


  Conditions on recipient of the transfer:

    - The recipient entity must be a current ARIN account holder.

    - The recipient must sign an RSA with ARIN.

    - The recipient entity of the transferred resources will be subject
      to current ARIN policies. In particular, in any subsequent ARIN
      IPv4 address allocation request, the recipient will be required
      to account for the efficient utilization of all IPv4 address
      space held, including all transferred resources.

and request the AC to modify section 8 of the current RSA to remove 
references to "intended purposes."

Replace
ARIN may review, at any time, Applicant's use of previously allocated or 
assigned number resources or Services received from ARIN to determine if 
Applicant is complying with this Agreement and the Policies and is using the 
Services for their intended purposes.  Without limiting the foregoing, if 
Applicant is a holder of a direct allocation or assignment from ARIN, 
Applicant agrees that it will use the number resources solely for uses 
consistent with its application and this Agreement, including, for example, 
its internal infrastructure or to provide Internet access to its customer 
base. If ARIN determines that the number resources or any other Services are 
not being used in compliance with this Agreement, the Policies, or the 
purposes for which they are intended, ARIN may: (i) revoke the number 
resources; (ii) cease providing the Services to Applicant; and/or (iii) 
terminate this Agreement.

with

ARIN may review, at any time, any Applicant's use of previously allocated or 
assigned number resources or Services received from ARIN to determine if 
Applicant is complying with this Agreement and the Policies.  Without 
limiting the foregoing, if Applicant is a holder of a direct allocation or 
direct assignment from ARIN, Applicant agrees that it will use the number 
resources solely for uses consistent with this Agreement, including, for 
example, its internal infrastructure or to provide Internet access to its 
customer base. If ARIN determines that the number resources or any other 
Services are not being used in compliance with this Agreement or the 
Policies, ARIN may: (i) revoke the number resources; (ii) cease providing 
the Services to Applicant; and/or (iii) terminate this Agreement.

and add to the NRPM Section 12:

10.    ARIN will not use utilization as a measure of policy compliance for 
addresses transferred under 8.3.


8. Rationale:


Current ARIN policies relating to the registration of transfer of
address holdings limit the eligibility of registration of transfers to
those relating to mergers and acquisitions of entities that are
administering an operational network, or to those who agree to
sign either an RSA or LRSA with ARIN and subject the buyer
to needs analysis and the seller to a potential ARIN review under RSA 
section 8.

It is currently anticipated that the IPv4 unallocated address pool
will be exhausted within a couple of years at ARIN, and earlier
than that in other regions, and the  transition to IPv6-based service 
delivery
is likely to take longer than the remaining period of unallocated
address availability. Accordingly, it is likely that demand for IPv4
addresses will continue beyond the time of unallocated address pool
exhaustion, leading to a period of movement of IPv4 address blocks
between address holders to meet such continuing demand for IPv4
address blocks.

The underlying proposition behind this policy proposal is that the
registry of IPv4 addresses operated by ARIN is of general utility and
value only while it accurately describes the current state of address
distribution. If a class of address movement transactions are excluded
from being entered in the registry, then the registry will have
decreasing value to the broader community, and the integrity of the
network itself is thereby compromised.  This proposal's central aim is
to ensure the continuing utility and value of the ARIN address
registry by allowing the registry to record transactions where IPv4
addresses are transfered between ARIN account holders.

It proposes that ARIN will recognise and register a transfer of
addresses where the parties to the transfer are 'known' to ARIN and
that the address block being transferred is part of ARIN's current address 
set.

The proposal does not prescribe how such transfers may occur, nor
impose any further constraints on the transfer or on the parties
involved other than those described in this proposal.

9. Timetable for implementation: immediate.



________________________________
This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the 
sender immediately and permanently delete the original and any copy of this 
E-mail and any printout.