[arin-ppml] ARIN-prop-151 Limiting Needs Requirements forIPv4 Transfers
Mike Burns
mike at nationwideinc.com
Mon Jun 6 23:11:23 EDT 2011
Hi Marla and thanks for the feedback.
The reason for the two items being part of the one proposal is that we need
to change the RSA to prevent ARIN from initiating a review and revokation
immediately after a needs-free transfer.
If we just take your item 3, which I love, and leave out the changes to the
RSA, we leave the door open for a needs test on the newly transferred
addresses, effectively mooting the idea of a needs-free transfer.
The limit of the /12 of needs free transfers is something I included due to
feedback about protection from hoarders and speculators. I would hope that
if data shows that this limit precludes the development of legitimate
business pursuits which require larger needs-free transfers, for example if
the market developed to a point where it was economically desirable for a
large wholesaler of addresses to traffic in larger amounts, I would support
a review of this limit.
I share your view that the fear of market manipulation is overblown, and
considered this a halfway step which could be revisited if our hunch is
correct, and no such market cornering appears to occur.
I thought it important that the transferee sign some kind of registration
agreement, but I wanted one which would not be so onerous as to cause
transactions to happen "off the books." My proposed changes to the RSA are
limited to removing ARIN's review and revokation procedures for utilization.
By this I meant to induce even legacy transferees to sign the RSA, and to
provide equal footing for existing RSA signatories who may wish to sell some
of their allocation without risking the triggering of a section 12 review.
As to your second point, my argument is that existing 8.3 policy was
manhandled in the public MS/Nortel deal, and in particular the needs-test
presented the element which most directly risked a transfer from Nortel to
MS without including ARIN at all. Other aspects of 8.3 which were hard to
find in the public details of the deal include the requirement of the seller
to sign an RSA or LRSA, the requirement of the buyer to sign an RSA, the
requirement of single aggregate transfer, and the requirement for the
addresses to be issued back to ARIN for reissuance to the buyer. Most of
these things were finessed through semantics, but that couldn't happen with
the needs-test. Fortunately MS established a need which matched the
negotiated sale amount.
So I think leaving 8.3 as it is to see how it goes runs the risk that the
market will start off on the wrong foot, with ARIN transfer requirements not
really meshing with the legal realities of legacy transfers. Better in my
mind for ARIN to initiate a liquid and vital market with protections for
buyers and sellers from ARIN transactional hurdles which risk accurate Whois
registration.
Regards,
Mike Burns
----- Original Message -----
From: "Azinger, Marla" <Marla.Azinger at FTR.com>
To: "ARIN" <info at arin.net>; <arin-ppml at arin.net>
Sent: Monday, June 06, 2011 7:55 PM
Subject: Re: [arin-ppml] ARIN-prop-151 Limiting Needs Requirements forIPv4
Transfers
>I don't support this as written.
>
> 1. I would like to see the two parts separated into different proposals.
> 2. I would need to see how current policy on the table goes before trying
> to change anything more in section 8.3
> 3. I would support policy that says "ARIN will not use utilization as a
> measure of policy compliance for addresses transferred." Conservation in
> the grand scheme has been achieved as much as possible. At this point in
> time any hoarding that might occur is really short term in the grand
> scheme. The worst case scerio that was used as a fear factor (scenerio
> was that some large entity would by up all the remaining space on the
> market and force other business out of business) in the past, doesnt even
> look possible in the present, so protecting against hoarding on the grand
> scheme is really pointless. Taking action to protect against this could
> even possibly be more damaging then helpful when you consider the services
> that could end up in a temporary halt because they werent ablet to create
> a transition time frame.
>
> Cheers
> Marla
>
> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of ARIN
> Sent: Wednesday, May 18, 2011 10:06 AM
> To: arin-ppml at arin.net
> Subject: [arin-ppml] ARIN-prop-151 Limiting Needs Requirements for IPv4
> Transfers
>
> ARIN-prop-151 Limiting Needs Requirements for IPv4 Transfers
>
> Corrected proposal name.
>
> ARIN received the following policy proposal and is posting it to the
> Public Policy Mailing List (PPML) in accordance with the Policy
> Development Process.
>
> The ARIN Advisory Council (AC) will review the proposal at their next
> regularly scheduled meeting (if the period before the next regularly
> scheduled meeting is less than 10 days, then the period may be extended to
> the subsequent regularly scheduled meeting). The AC will decide how to
> utilize the proposal and announce the decision to the PPML.
>
> The AC invites everyone to comment on the proposal on the PPML,
> particularly their support or non-support and the reasoning behind their
> opinion. Such participation contributes to a thorough vetting and provides
> important guidance to the AC in their deliberations.
>
> Draft Policies and Proposals under discussion can be found at:
> https://www.arin.net/policy/proposals/index.html
>
> The ARIN Policy Development Process can be found at:
> https://www.arin.net/policy/pdp.html
>
> Mailing list subscription information can be found
> at: https://www.arin.net/mailing_lists/
>
> Regards,
>
> Communications and Member Services
> American Registry for Internet Numbers (ARIN)
>
>
> ## * ##
>
>
> ARIN-prop-151 Limiting Needs Requirements for IPv4 Transfers
>
> Proposal Originator: Mike Burns
>
> Proposal Version: 1
>
> Date: 18 May 2011
>
> Proposal type: modify
>
> Policy term: permanent
>
> 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.
>
> - If the recipient has already received the equivalent of a /12
> of addresses in the prior 12 months, the recipient must
> demonstrate the need for additional resources in the exact amount
> which they can justify under current ARIN policies.
>
> 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.
>
>
> 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.
>
> Timetable for implementation: immediate.
>
>
>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to the ARIN
> Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>
> This communication is confidential. Frontier only sends and receives
> email on the basis of the terms set out at
> http://www.frontier.com/email_disclaimer.
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
More information about the ARIN-PPML
mailing list