<br>David,<br>
<br>
Based on the public and other private feedback, I think a modification as such would be useful. I was trying to maintain the language in the form that it was prior to my modification suggestions, but it is proving to be very difficult to do that and write effective public policy. I'm offering a complete rewrite with a clear delineation between legacy and non-legacy v4 addresses and ASN's.<br>

<br>
8.3 Transfers to Specified Recipients<br>
<br>
8.3.1 Transfer of non legacy IPv4 and ASN's<br>
<br>
In addition to transfers under section 8.2, IPv4 number resources and<br>
16 bit ASN's may be released to ARIN by an authorized resource holder or by another RIR, in<br>
whole or in part, for transfer to another specified organizational<br>
recipient. Organizations in the ARIN region may receive transferred<br>
IPv4 number resources under RSA if they can demonstrate that the need for such<br>
resources exists and in the amount that they can justify under current<br>
ARIN policies.<br>
<br>
8.3.2 Transfer of legacy IPv4 addresses and ASN's<br>
<br>
IPv4 address resources and ASN's may be transferred to<br>
organizations in another RIR's service region if they demonstrate need to their region's RIR and<br>
compliance with that RIR's policies. IPv4 number resources may be<br>
transferred in blocks of the minimum allocation unit of the recipient RIR and will remain the property of the transforee.<br>
<br>
8.3.3 Legacy Agreements and Assessments<br>
<br>
Needs assessments or services agreements with ARIN are not required<br>
for legacy resource transfers. In the case of ASN's, a multi homing required is waived for the purpose of transfer.<br>
<br>
8.3.4 Notice of Refusal<br>
<br>
ARIN will provide a written and detailed notice that includes the<br>
specific reasons why when refusing any number resource or ASN transfer.  This<br>
notice will be provided to all parties to a transfer.<br>
<br>
<br>
Rationale:<br>
<br>
<br>
To further increase the utilization of available but unused legacy ASN's in order<br>
to stimulate 32 bit ASN uptake. The resulting benefit will be realized<br>
over (a shorter period of) time as ASN's are used from<br>
both pools of addresses and software, systems and processes integrate<br>
the same to accommodate an eventual compatibility of both pools<br>
instead of partial backwards compatibility overall. It is recommended that ARIN revisit its own internal assignment policies and allow<br>for the request of specific ASN's from an undifferentiated pool of ASN's in order to create a spread of requests and collateral uptake.<br>


<br>
With regards to the language modifications related to v4 number<br>
resources, suggested modifications will pull the stop on the legacy<br>
market and make it "more" attractive to voluntarily adhere to ARIN community established<br>
policies as well as increase the reliability of ARIN whois data and ultimately create a more fair and balanced environment for market purchases that includes transparency. This proposal also provides a mechanism for continued drainage of the available v4 pool effectually stimulating uptake in IPv6 as well. Increased uptake of v6 and 32 bit ASN's are both stated objectives of the Internet technical community and are desirable.<br>


<br>
This proposal would also result in greater value to debtors related to legacy assets in a bankruptcy process by removing uncertainties and unknowns created by vague and unclear policy related to legacy addresses and ASN's.<br>

<br>Best,<br><br>-M<<br><br>
<br>