[arin-ppml] Draft Policy 2012-3: ASN Transfers

[Jimmy Hess]

On Wed, Mar 14, 2012 at 10:07 AM, ARIN <info at arin.net> wrote:
> There are legitimate use cases for transferring ASNs, and no significant
> downsides (identified to date) of allowing it.

Opposed to this proposal; it appears to be unnecessary scope creep for
the 8.3 IPv4 transfer policy.
unless that network is transferred together with its network
equipment/IP resources and ASN under 8.2, AND a separate routing
policy will be maintained for IP addresses after the transfer;  a new
ASN should be allocated,  (or the existing AS should be required to be
used when 8.3 transferred IP addresses will not have a distinct
routing policy  and the transfer recipient already has an AS).

An ASN should not be transferrable to an unrelated entity without the
IP resources associated with that ASN, because an ASN is an
identification of the administrative division, and not an addressing
resource.

By definition, you have a new AS,  therefore a new AS ID number should
be assigned to this new AS, and the old one should be retired and not
be reallocated for some amount of time.  The significant downside is
that allowing the free transfer of ASNs breaks the stability of the
administrative ID.

Because the ID number relates to routing policy, the unexpected
transferrance of such ID may cause confusion or have unwanted effects
on other networks'   treatment of the AS in regards to routing policy.

For example,  the previous holder of the AS might have had a bad
reputation, a position of trust,
or  relationships with other networks that caused their AS number to
appear in various kinds of policy lists.

There is also no danger of AS exhaustion, since the field was extended
to 32 bits many years ago, therefore, no significant need for the
transfer of AS.

--
-JH