[ppml] Policy Proposal: IPv4 Transfer Policy Proposal

[Scott Leibrand]

Jim Weyand wrote:
> Scott-
>
> I copied section 8.4.2 and added your new language as the final bullet
> point.  I assume this is how you want it to read.
>   

Yeah, I did the order slightly differently, but that doesn't matter 
except for readability.  It'll go into version 1.1 of the proposal.

> As I reflect on your proposal I have some thoughts.
>
> 1) Must a transferee receive all allowed addresses in a single
> transaction from a single transferor?  Because your new language says,
> "receive a contiguous CIDR block" I assume that is your intent.  I
> understand that there are router table issues here
Correct.
>  and I am a businessman not a technologist
That's good: we need more perspectives like yours.
>  but it seems if I am pre-qualified to
> receive a /16 and I find two /17s that are already advertised they can
> be moved to my address space with no net effect on the router table.

There's no direct effect on the routing table from that, but taking 
those two /17's means that someone who only needs a /17 will likely have 
to split a larger block to get it.  Over time, average netblock size has 
decreased, and it will likely continue to do so.  Therefore, we will 
have to allow deaggregation to meet the needs of ever-smaller netblocks, 
but we shouldn't encourage more deaggregation than necessary by using 
two smaller netblocks in place of one larger one.

> I can see the potential problem where several entities have been
> pre-qualified as transferors of a /16 and begin transferring /20s
> (possibly because the market has valued them higher) and my transferee
> above puts together his /16 worth of address space by purchasing (I
> think I did the math right) 8 /20s from different holders resulting in
> significant additional entries in the routing table.
>
> One solution to this is to allow the transfers but charge a transfer fee
> for each transaction that increases the size of the router table.  My
> rationale for the additional fee is that all members of the community
> bear some additional cost and individual entities that cause the
> additional cost should bear some burden.
>   

That would in theory be a sensible solution, and is very similar to the 
approach I feel governments should take to pollution-related 
externalities.  However, ARIN is not a government, and needs to be very 
careful not to use fees in a punitive manner.  Others can speak to those 
issues more than I, but my general impression is that while ARIN can 
charge fees for services performed (such as the work of transferring a 
registration), those fees can't be disproportionately high, which is 
what would be required to have an economic impact on deaggregation.

> 2) I know there is a great concern in the community with speculators
> that might buy and sell address space for a profit.  However the
> unintended consequence of putting too many barriers to trade is that a
> "gray market" will develop that will be outside of the control of the
> RIR.  I understand from posts I have read here today that such a thing
> is already happening.  
>
> Maybe this is not a problem and I am worrying about something that has
> no effect.
>   

Yes, this is a valid concern.  The main concern about speculation is 
that the price to transfer IPv4 address resources will likely track 
along something like a bell curve (price rising as free supply is used 
up, then later falling as people finish moving to IPv6), so if 
speculators are allowed to acquire addresses while the price is going up 
(with the hope of selling them as the price continues to go up), that 
will steepen the bell curve, causing a classic boom-and-crash pattern.  
This would, of course, raise the cost of acquiring IPv4 address 
resources when they're needed the most, and then flood the market with 
cheap addresses after they're no longer really needed.

In order to control this, I think we need to ensure that the actual 
transfer of IPv4 address registrations occurs between legitimate address 
holders and organizations with a legitimate need for IPv4 addresses 
who'll actually use them.  Private contracts of various sorts are 
possible to deal with the financial and timing issues, but at the end of 
the day when ARIN goes to complete the transfer, the addresses need to 
go to the network who'll be using them.

There is definitely a small black market in IPv4 addresses today, and 
will likely be a much larger gray market later on if we don't implement 
a transfer policy, or do so poorly.  I personally don't believe that 
steps taken to prevent speculation will encourage use of whatever gray 
market does exist: in fact, I would argue that our success at that will 
encourage use of the legitimate market.

Are there any specific transfer conditions that you feel constitute more 
of a barrier to trade than is justified?

> Thanks again for your work.  You have shown great patience explaining
> your proposal to all involved.
>   

Thanks.  And thank you (and everyone else who's posted) for 
participating in this discussion and providing constructive feedback.

-Scott
> -----Original Message-----
> From: Scott Leibrand [mailto:sleibrand at internap.com] 
> Sent: Wednesday, February 13, 2008 11:13 AM
> To: Jim Weyand
> Cc: ppml at arin.net
> Subject: Re: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal
>
> Jim,
>
> Reading over 4.2 and 4.3 of the NRPM, I see lots of different conditions
>
> for different types of networks.  Specifically, the text in 4.2.2.1.3 
> and 4.2.2.2.2 requiring that the requested IP address space will be 
> utilized within three months refers to organizations justifying an 
> initial allocation on the basis of their use of PA space, and is 
> intended to minimize delay in renumbering out of PA space (if 
> applicable) and beginning to use and route the new space.  As I read 
> those sections, they don't require 100% utilization within three months.
>
> However, in 4.2.4.3 and 4.2.4.4, it does appear that a new ISP that 
> needs additional space before they've been an ARIN member for a year can
>
> only justify a three-month supply of addresses.  After that, they can 
> get six months' worth.  In the case of end users, they can get over a 
> year's worth of space according to 4.3.3.
>
> Given all this confusion, I'd like to decouple the 8.4 transfer policy's
>
> transfer sizes somewhat from the allocation and assignment sizes in 4.2 
> and 4.3, by adding the following bullet point to 8.4.2:
>
>     * The transferee may request and receive a contiguous CIDR block
>       large enough to provide a 12 month supply of IPv4 addresses.
>
> That will preserve the requirement that need and efficient use are 
> justified, but would bypass the sections of 4.2 and 4.3 concerned with 
> preventing hoarding (intentional or otherwise).  My assumption here is 
> that the cost of transferring addresses and a 12-month supply rule would
>
> act as a sufficient brake to prevent anyone from getting more addresses 
> than they need for that timeframe.  The 12-month supply should also be 
> sufficient, in concert with the one-block-every-6-months condition, to 
> ensure that transferees get enough address space to limit unnecessary 
> deaggregation.
>
> Thoughts?
>
> -Scott
>   
>>             4.2.2.1.3. Three months
>>
>> Provide detailed information showing specifically how a /20 will be 
>> utilized within three months.
>>
>>
>>             4.2.2.2.2. Three months
>>
>> Provide information showing that the requested IP address space will 
>> be utilized within three months and demonstrating an intent to 
>> announce the requested space in a multihomed fashion.
>>
>>
>>             4.2.2.2.4. Additional requests following the initial
>>             allocation
>>
>> To receive additional address space following the initial allocation, 
>> multihomed organizations must have returned the original IP address 
>> space to its provider in its entirety and must provide justification 
>> for a new allocation as described above in the section titled 
>> Requirements for Requesting Initial Address Space.
>>
>>
>>           4.2.4.3. Three months
>>
>> Provide detailed information showing specifically that the address 
>> space will be utilized within three months. Determination of the 
>> appropriate allocation to be issued is based on efficient utilization 
>> of space within this three-month time frame.
>>
>>
>>           4.2.4.4. Six months
>>
>> After a subscriber has been a member of ARIN for one year they may 
>> choose to request a six-month supply of IP addresses.
>>
>>
>>         4.3.3. Utilization rate
>>
>> Utilization rate of address space is a key factor in justifying a new 
>> assignment of IP address space. Requesters must show exactly how 
>> previous address assignments have been utilized and must provide 
>> appropriate details to verify their one-year growth projection. The 
>> basic criteria that must be met are:
>>
>>     * A 25% immediate utilization rate, and
>>     * A 50% utilization rate within one year.
>>
>>     
>
>
> Scott Leibrand wrote:
>   
>> No, I think that reflects my failure to actually re-read 4.2.2 when 
>> writing 8.4.3.  :-)  I'll look into that and see what revisions are 
>> needed are needed to make them consistent.  Good catch.
>>
>> Thanks,
>> Scott
>>
>> Jim Weyand wrote:
>>   
>>     
>>> Well done!  However I see one small issue that probably reflects my
>>>       
> lack
>   
>>> of understanding:
>>>
>>> Section 8.4.3 of the proposal below references NRPM 4.2.2. regarding
>>> minimum allocation size and section 8.4.1 says, "The transferee may
>>>       
> only
>   
>>> receive one IPv4 address transfer every 6 months."  
>>>
>>> However NRPM 4.2.2.2.2. says, " Provide information showing that the
>>> requested IP address space will be utilized within three months and
>>> demonstrating..."
>>>
>>> Which of course would mean that, to be consistent with the NRPM, a
>>> transferee could only buy a three month supply of addresses every six
>>> months.
>>>
>>>   
>>> -----Original Message-----
>>> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf
>>>       
> Of
>   
>>> Member Services
>>> Sent: Monday, February 11, 2008 11:35 AM
>>> To: ppml at arin.net
>>> Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal
>>>
>>> Resending with a typo that has been corrected in 8.4.2 below. The 
>>> original text is supposed to have "24 months" twice in that section.
>>>
>>> Member Services
>>> American Registry for Internet Numbers (ARIN)
>>>
>>>
>>>
>>>
>>> ARIN received the following policy proposal. In accordance with the
>>>       
> ARIN
>   
>>> Internet Resource Policy Evaluation Process, the proposal is being
>>> posted to the ARIN Public Policy Mailing List (PPML) and being placed
>>>       
> on
>   
>>> ARIN's website.
>>>
>>> The ARIN Advisory Council (AC) will review this proposal at their
>>>       
> next
>   
>>> regularly scheduled meeting. The AC may decide to:
>>>
>>>    1. Accept the proposal as written. If the AC accepts the proposal,
>>>       
> it
>   
>>> will be posted as a formal policy proposal to PPML and it will be
>>> presented at a Public Policy Meeting.
>>>
>>>    2. Not accept the proposal. If the AC does not accept the
>>>       
> proposal,
>   
>>> the AC will explain their decision via the PPML. If a proposal is not
>>> accepted, then the author may elect to use the petition process to
>>> advance their proposal. If the author elects not to petition or the
>>> petition fails, then the proposal will be closed.
>>>
>>> The AC shepherds for this proposal are Scott Leibrand and Stacy
>>>       
> Taylor.
>   
>>> The AC invites everyone to comment on this 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.
>>>
>>> The ARIN Internet Resource Policy Evaluation Process can be found at:
>>> http://www.arin.net/policy/irpep.html
>>>
>>> Mailing list subscription information can be found at:
>>> http://www.arin.net/mailing_lists/
>>>
>>> Regards,
>>>
>>> Member Services
>>> American Registry for Internet Numbers (ARIN)
>>>
>>>
>>> ## * ##
>>>
>>>
>>> Policy Proposal Name: IPv4 Transfer Policy Proposal
>>>
>>> Author: ARIN Advisory Council
>>>
>>> Proposal Version: 1.0
>>>
>>> Submission Date: 02/07/2008
>>>
>>> Proposal type: modify
>>>
>>> Policy term: permanent
>>>
>>> Policy statement:
>>>
>>> Replace the current NRPM section 8 with the following --
>>>
>>> 8.         Transfers
>>>
>>> [8.1.     Transfers - retain as is:
>>>
>>> Number resources are non-transferable and are not assignable to any
>>> other organization unless ARIN has expressly and in writing approved
>>>       
> a
>   
>>> request for transfer.  ARIN is tasked with making prudent decisions
>>>       
> on
>   
>>> whether to approve the transfer of number resources.
>>>
>>> It should be understood that number resources are not "sold" under
>>>       
> ARIN
>   
>>> administration. Rather, number resources are assigned to an
>>>       
> organization
>   
>>> for its exclusive use for the purpose stated in the request, provided
>>> the terms of the Registration Services Agreement continue to be met
>>>       
> and
>   
>>> the stated purpose for the number resources remains the same. Number
>>> resources are administered and assigned according to ARIN's published
>>> policies.
>>>
>>> Number resources are issued, based on justified need, to
>>>       
> organizations,
>   
>>> not to individuals representing those organizations. Thus, if a
>>>       
> company
>   
>>> goes out of business, regardless of the reason, the point of contact
>>> (POC) listed for the number resource does not have the authority to
>>> sell, transfer, assign, or give the number resource to any other
>>>       
> person
>   
>>> or organization. The POC must notify ARIN if a business fails so the
>>> assigned number resources can be returned to the available pool of
>>> number resources if a transfer is not requested and justified.]
>>>
>>>
>>> [8.2 - remove the word "only", and retitle to "M&A Transfer
>>> Requirements":
>>>
>>> 8.2.      M&A Transfer Requirements
>>>
>>> ARIN will consider requests for the transfer of number resources upon
>>> receipt of evidence that the new entity has acquired the assets which
>>> had, as of the date of the acquisition or proposed reorganization,
>>> justified the current entity's use of the number resource. Examples
>>>       
> of
>   
>>> assets that justify use of the number resource include, but are not
>>> limited to:
>>>
>>>      * Existing customer base
>>>      * Qualified hardware inventory
>>>      * Specific software requirements.]
>>>
>>>
>>> [8.3 - retitle to "M&A Transfer Documentation Requirements":
>>>
>>> 8.3.      M&A Transfer Documentation Requirements
>>>
>>> In evaluating a request for transfer, ARIN may require the requesting
>>> organization to provide any of the following documents, as
>>>       
> applicable,
>   
>>> plus any other documents deemed appropriate:
>>>
>>>      * An authenticated copy of the instrument(s) effecting the
>>>       
> transfer
>   
>>>        of assets, e.g., bill of sale, certificate of merger,
>>>       
> contract,
>   
>>>        deed, or court decree
>>>      * A detailed inventory of all assets utilized by the requesting
>>>        party in maintaining and using the number resource
>>>      * A list of the requesting party's customers using the number
>>> resource.
>>>
>>> If further justification is required, the requesting party may be
>>>       
> asked
>   
>>> to provide any of the following, or other supporting documentation,
>>>       
> as
>   
>>> applicable:
>>>
>>>      * A general listing of the assets or components acquired
>>>      * A specific description of acquisitions, including:
>>>            o Type and quantity of equipment
>>>            o Customer base
>>>      * A description of how number resources are being utilized
>>>      * Network engineering plans, including:
>>>            o Host counts
>>>            o Subnet masking
>>>            o Network diagrams
>>>            o Reassignments to customers]
>>>
>>> 8.4.      Requirements for Simple Transfer of IPv4 Addresses
>>>
>>> After the exhaustion of the IANA IPv4 free pool, ARIN will also
>>>       
> process
>   
>>> IPv4 address transfer requests subject to the following conditions.
>>>
>>> 8.4.1    Conditions on the transferor:
>>>
>>>      * The transferor resides in the ARIN service area.
>>>      * The transferor has signed an RSA and/or a legacy RSA covering
>>>       
> the
>   
>>>        IPv4 addresses transferred.
>>>      * The transferor has no outstanding balances with ARIN.
>>>      * The transferor has not received any IPv4 allocations or
>>>        assignments from ARIN (through ordinary allocations or
>>>        assignments, or through this Simple Transfer policy) within
>>>       
> the
>   
>>>        preceding 24 months.
>>>      * The transferor may not request any IPv4 allocations or
>>> assignments
>>>        from ARIN (through ordinary allocations or assignments, or
>>> through
>>>        this Simple Transfer policy) within the subsequent 24 months.
>>>
>>> 8.4.2    Conditions on the transferee:
>>>
>>>      * The transferee resides in the ARIN service area and intends to
>>> use
>>>        the transferred IPv4 addresses within the ARIN service area.
>>>      * The transferee has no outstanding balances with ARIN.
>>>      * The transferee's need is confirmed by ARIN, according to
>>>       
> current
>   
>>>        ARIN policies, including but not limited to confirmation of
>>>        utilization rate of any prior IPv4 allocations, assignments,
>>>       
> or
>   
>>>        previously transferred IPv4 addresses held by the transferee.
>>>      * The transferee signs (or has previously signed) an RSA
>>>       
> covering
>   
>>>        the IPv4 addresses transferred.
>>>      * The transferee has not provided any IPv4 addresses for
>>>       
> transfer
>   
>>>        through this Simple Transfer process within the preceding 24
>>>        months.
>>>      * The transferee may not provide any IPv4 addresses for transfer
>>>        through this Simple Transfer process within the subsequent 24
>>>        months, except in the case of business failure.
>>>      * The transferee may only receive one IPv4 address transfer
>>>       
> every 6
>   
>>>        months.
>>>
>>>
>>>
>>> 8.4.3    Conditions on the IPv4 address block to be transferred:
>>>
>>>      * The IPv4 block must comply with applicable ARIN requirements,
>>>        including minimum allocation size (i.e. NRPM 4.2.2., 4.2.4.,
>>>        4.3.2., 4.3.6.).  However, an IPv4 allocation or assignment of
>>> /24
>>>        or larger, but smaller than the current minimum allocation
>>>       
> size,
>   
>>>        may be transferred as a whole resource, but may not be
>>> subdivided.
>>>      * The IPv4 block must currently be registered for use within the
>>>        ARIN service area, either as part of an address block assigned
>>>       
> by
>   
>>>        IANA to ARIN, or as part of a legacy address block allocated
>>>        within the ARIN service area.
>>>      * There must exist no dispute as to the status of the IPv4 block
>>>       
> or
>   
>>>        regarding the allocation or assignment of such block to the
>>>        transferor.
>>>      * The transferor may retain one contiguous address range out of
>>>        their original allocation or assignment for their own use, and
>>>        transfer the other contiguous address range.  If the address
>>> range
>>>        to be transferred consists of multiple non-aggregatable CIDR
>>>        blocks, each may be transferred to a different transferee.
>>>       
> The
>   
>>>        retained address range may not be further subdivided or
>>>        transferred for a period of 12 months.
>>>
>>> 8.4.4    Fees
>>>
>>>      * Completion of a transfer requires payment of a transfer fee
>>>        according to ARIN's schedule of fees.
>>>      * The transferee will be subject to all future ARIN membership
>>>       
> and
>   
>>>        service fees according to the transferee's total address
>>> holdings.
>>>
>>> 8.4.5    Pre-qualification
>>>
>>>      * An interested transferee must seek pre-qualification from ARIN
>>>       
> to
>   
>>>        confirm its eligibility to receive a transfer (including
>>>        satisfaction of need according to current ARIN policies)
>>>       
> before
>   
>>>        making any solicitation for transfer.  Upon pre-qualification,
>>>        ARIN will provide the transferee with documentation of the
>>>        pre-qualification, including the size (CIDR prefix length) of
>>>       
> the
>   
>>>        largest IPv4 address block the transferee is eligible to
>>>       
> receive,
>   
>>>        and the expiration date of the pre-qualification.
>>>      * An interested transferor must seek pre-qualification from ARIN
>>>       
> to
>   
>>>        confirm its eligibility to offer a transfer (including lack of
>>>        outstanding balances and having signed an RSA) before offering
>>>        IPv4 address resources for transfer.  Upon pre-qualification,
>>> ARIN
>>>        will provide the transferor with documentation of the
>>>        pre-qualification, including the exact network address and
>>>       
> size
>   
>>>        (CIDR prefix length) the transferor is eligible to provide,
>>>       
> and
>   
>>>        the expiration date of the pre-qualification.
>>>
>>> 8.5.      Safe Harbor for IPv4 Transfers through this Simple Transfer
>>> Process
>>>
>>> IPv4 address resources being made available for transfer shall be
>>>       
> exempt
>   
>>> from ARIN audit until expiration of the transfer pre-qualification or
>>> completion of the transfer.  In the event that a transfer
>>> pre-qualification expires, ARIN shall have up to 90 days to initiate
>>>       
> an
>   
>>> audit prior to this exemption being reinstated through subsequent
>>> transfer pre-qualification. This will not extend the end of the
>>> exemption.
>>>
>>> 8.6.      Simple IPv4 Transfers to or from Organizations Under Common
>>> Ownership or Control
>>>
>>> If an IPv4 transferor or transferee is under common ownership or
>>>       
> control
>   
>>> with any other organization that holds one or more IPv4 blocks, the
>>>       
> IPv4
>   
>>> transfer request must report all such organizations under common
>>> ownership or control.
>>>
>>> When evaluating compliance with IPv4 Simple Transfer conditions, ARIN
>>> may consider a transferor's transfer request in light of requests
>>>       
> from
>   
>>> other organizations under common ownership or control with the
>>> transferor.  Similarly, ARIN may consider a transferee's request in
>>> light of requests from other organizations under common ownership or
>>> control with the transferee.  In evaluating requests from other
>>> organizations under common ownership or control, ARIN staff will
>>> consider the relationship between the organizations, the degree of
>>> coordination between the organizations, and the bona fide use of the
>>> addresses at issue to determine whether all appropriate conditions
>>>       
> are
>   
>>> met.
>>>
>>> 8.7.      Record-keeping and Publication of Simple Transfers of IPv4
>>> Addresses
>>>
>>> ARIN will develop and operate a listing service to assist interested
>>> transferors and transferees by providing them a centralized location
>>>       
> to
>   
>>> post information about IPv4 blocks available from prequalified
>>> transferors and IPv4 blocks needed by prequalified transferees.
>>>
>>> After completion of the transfer, ARIN will update the registration
>>> records pertaining to the IPv4 block at issue.  ARIN will adjust its
>>> records as to the holdings of the transferor and transferee.
>>>
>>> After the transfer, ARIN will publish WHOIS data that reflects the
>>> current allocation or assignment of the transferred block.  ARIN will
>>> also make available information about any prior recipient(s) of such
>>> block.  ARIN will also publish a log of all transfers, including
>>>       
> block,
>   
>>> transferor, transferee, and date.
>>>
>>>
>>> Rationale:
>>>
>>> The ARIN Board of Trustees asked the Advisory Council to consider a
>>>       
> set
>   
>>> of questions around the depletion of the free pool of IPv4 addresses,
>>> the transition to IPv6 for Internet address needs in the future, and
>>> ARIN's possible role in easing the transition.
>>>
>>> Over the past few years the AC has spent a great deal of time
>>>       
> reflecting
>   
>>> on these issues as a group, as individuals, and in consultation with
>>> the community. One outcome of this process is this policy proposal,
>>> which the AC is submitting for consideration at the next meeting. We
>>>       
> are
>   
>>> proposing some changes to existing ARIN policy regarding the transfer
>>>       
> of
>   
>>> IP address block registrations between subscribers, which will allow
>>>       
> for
>   
>>> the emergence of trade in IPv4 address space, with ARIN to provide a
>>> listing service for address blocks available for transfer under the
>>> liberalized policy.  We are aware that this proposal, if adopted,
>>>       
> will
>   
>>> mark a major change in ARIN's role in the community and the Internet.
>>>
>>> This policy proposal would create a transfer mechanism for IPv4
>>>       
> number
>   
>>> resources between those who have excess resources and those who have
>>>       
> a
>   
>>> need, thereby allowing ARIN to continue to serve its mission after
>>>       
> IANA
>   
>>> free pool exhaustion.  This proposal would also set conditions on
>>>       
> such
>   
>>> transfers intended to preserve as much as possible the existing
>>>       
> policy
>   
>>> related to efficient, needs-based resource issuance, and would
>>>       
> leverage
>   
>>> ARIN's extensive control systems, audit trails, and recognized
>>>       
> position
>   
>>> as a trusted agent to avoid speculation and hoarding and diminish the
>>> likelihood and extent of an uncontrolled 'black market' where the
>>>       
> risk
>   
>>> and potential for fraud is immeasurably higher.
>>>
>>> Many of the transfer conditions are self-explanatory, but some worth
>>> highlighting are that:
>>>
>>>      * To discourage speculation, a waiting period (proposed at 24
>>>        months) is required before a transferee (or ordinary resource
>>>        recipient) can become a transferor, or vice versa.
>>>      * Transferees must qualify for IPv4 space (just as they do today
>>>        when getting it from ARIN) before they can receive address
>>>       
> space
>   
>>>        by transfer, or solicit space on a listing service.
>>>      * To discourage unnecessarily rapid growth of routing tables, an
>>>        allocation or assignment may not be arbitrarily deaggregated.
>>>       
> To
>   
>>>        allow a transferor to downsize within their existing space,
>>>       
> they
>   
>>>        may split off a contiguous address range, once every 12
>>>       
> months,
>   
>>>        and transfer the resulting netblock(s), which are subject to
>>>        ARIN's minimum allocation size, to one or more transferee(s).
>>>      * A transferee may receive one transfer every 6 months, so
>>>       
> they'll
>   
>>>        be incented to transfer a block appropriately sized for their
>>>        needs, which will further discourage deaggregation and keep
>>>        smaller blocks available for smaller organizations.
>>>
>>> The proposal would also have ARIN develop and operate a listing
>>>       
> service
>   
>>> to facilitate transfers and provide an authoritative central source
>>>       
> of
>   
>>> information on space available and requested for transfer.  It would
>>>       
> not
>   
>>> prohibit private party transactions, but would require that potential
>>> transferors and transferees be pre-qualified first, so that neither
>>> party will encounter any unexpected surprises when they ask ARIN to
>>> process the transfer.
>>>
>>> Timetable for implementation: Immediately, with most aspects of
>>>       
> policy
>   
>>> taking effect upon IANA exhaustion, per the policy text.
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> PPML
>>> You are receiving this message because you are subscribed to the ARIN
>>> Public Policy
>>> Mailing List (PPML at arin.net).
>>> Unsubscribe or manage your mailing list subscription at:
>>> http://lists.arin.net/mailman/listinfo/ppml
>>> Please contact the ARIN Member Services Help Desk at info at arin.net if
>>> you experience any issues.
>>> _______________________________________________
>>> PPML
>>> You are receiving this message because you are subscribed to the ARIN
>>>       
> Public Policy
>   
>>> Mailing List (PPML at arin.net).
>>> Unsubscribe or manage your mailing list subscription at:
>>> http://lists.arin.net/mailman/listinfo/ppml
>>> Please contact the ARIN Member Services Help Desk at info at arin.net if
>>>       
> you experience any issues.
>   
>>>   
>>>     
>>>       
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to the ARIN
>>     
> Public Policy
>   
>> Mailing List (PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/ppml
>> Please contact the ARIN Member Services Help Desk at info at arin.net if
>>     
> you experience any issues.
>   
>>   
>>