[arin-ppml] Additional modifications to Section 8.3 related to ASN's and legacy addresses

[Martin Hannigan]

David,

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.

8.3 Transfers to Specified Recipients

8.3.1 Transfer of non legacy IPv4 and ASN's

In addition to transfers under section 8.2, IPv4 number resources and
16 bit ASN's may be released to ARIN by an authorized resource holder or by
another RIR, in
whole or in part, for transfer to another specified organizational
recipient. Organizations in the ARIN region may receive transferred
IPv4 number resources under RSA if they can demonstrate that the need for
such
resources exists and in the amount that they can justify under current
ARIN policies.

8.3.2 Transfer of legacy IPv4 addresses and ASN's

IPv4 address resources and ASN's may be transferred to
organizations in another RIR's service region if they demonstrate need to
their region's RIR and
compliance with that RIR's policies. IPv4 number resources may be
transferred in blocks of the minimum allocation unit of the recipient RIR
and will remain the property of the transforee.

8.3.3 Legacy Agreements and Assessments

Needs assessments or services agreements with ARIN are not required
for legacy resource transfers. In the case of ASN's, a multi homing
required is waived for the purpose of transfer.

8.3.4 Notice of Refusal

ARIN will provide a written and detailed notice that includes the
specific reasons why when refusing any number resource or ASN transfer.
 This
notice will be provided to all parties to a transfer.


Rationale:


To further increase the utilization of available but unused legacy ASN's in
order
to stimulate 32 bit ASN uptake. The resulting benefit will be realized
over (a shorter period of) time as ASN's are used from
both pools of addresses and software, systems and processes integrate
the same to accommodate an eventual compatibility of both pools
instead of partial backwards compatibility overall. It is recommended that
ARIN revisit its own internal assignment policies and allow
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.

With regards to the language modifications related to v4 number
resources, suggested modifications will pull the stop on the legacy
market and make it "more" attractive to voluntarily adhere to ARIN
community established
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.

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.

Best,

-M<
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20120523/5dfb4da3/attachment.htm>