[arin-ppml] ARIN-prop-171 Section 8.4 Modifications: ASN and legacy resources & ARIN-prop-172 Additional definition for NRPM Section 2 - Legacy Resources

Astrodog astrodog at gmx.com
Sat Jun 9 19:32:30 EDT 2012


On 6/9/2012 4:21 PM, Martin Hannigan wrote:
>
> Yes, I agree. This is entirely opposite our standards of conduct. 
>
> I ask that all re focus their attention on prop 171 and 172 and not
> worry about the property issue. 
>  It is irrelevant as related to these proposals. 
>
>
It seems a group of participants has certainly decided to use
inflammatory language... however, that should not deter discussions
about the property issue. The property issue seems to be the crux of
both proposals. In the case of 171, the entire basis of the proposal
centers around the property issue by granting explicit rights to legacy
holders and explicitly making legacy addresses very, very "special" in
terms of re-allocation, something the community does not appear to have
any consensus surrounding, particularly given the complete lack of
requirements for the entity obtaining the address beyond accurate whois
information. It also makes legacy address space special in perpetuity,
which also appears to run contrary to consensus. A more limited proposal
that applies only to the original or current "owner" may be
significantly more palpable, I don't know. 172 does not appear to
account for actions ARIN and some legacy holders have already taken...
it seems to be mutually exclusive with the facts on the ground as John
has reported them. I'm not sure I even see a way for ARIN to implement
this if it were to become policy.

Re: 171:

8.4.1 removes the compatibility test that exists for other transfers to
other RIRs under 8.3

8.4.2 is largely a non-op. Even if I can get a legacy /28, that doesn't
mean anyone will route it. Allocation blocks smaller than /24 are almost
certainly worthless to the kinds of entities that would be considering
transfers under this proposal.

8.4.3 explicitly states that a needs test, as would be required under
8.3, is to be waived.

8.4.5 works against the intent of the proposal, given the numbers of
legacy addresses where no such chain of custody exists. They simply
"spawned" into being. This isn't ARIN's problem to solve. Buyers should
obtain title insurance, or legal guarantees from sellers regarding the
title / chain of custody situation. The potential overhead for ARIN with
this section is also tremendous, as validating title and chain of
custody is a theoretically endless process once a resource passes
through a bankruptcy or, worse, has no origin whatsoever, simply because
someone forgot to write down the original transaction.

8.4.6 Define "fail chain of custody certifications"? To use a similar
situation that arises in real asset sales, simply because a building
cannot currently pass a title search and be sold, does not mean whoever
is presently occupying it is evicted. This section creates a massive
risk for sellers with all but the most impeccable records.

8.4.7 This section serves to deter legacy entities from entering into an
LRSA with ARIN at all.

There's really a very simple question for the community here: "Are
legacy addresses special *after* they have been transferred from their
original legacy 'owner'?"

As a consultant, 171 sounds great. I'm sure clients will end up paying
me for more of my time if it is approved. As a participant on the PPML,
it does not seem to serve its stated goals, and runs contrary to consensus.

Opposed.

Re: 172:

With part 2 of the definition... how would already returned addresses
that do not comply with part 2 be handled? In some cases, there is
likely to be no business to ask again, or worse, a new user of of the
space. Would these new users have clear title as it is defined by 171,
or would the addresses be revoked? It appears that under the definition
proposed, these re-allocated addresses would meet the definition of
legacy address and under 171, would then fail a chain of custody search.
This seems like screwing over a few random entities.

Until a satisfactory answer to the above comes out, I'm opposed to this
one as well.

If these proposals are supported by the community, lets revive -1 and
just thwack the needs test out of 8.3 and be done with this. 171 seems
to operate as an "end run" around the community's position regarding the
conditions of an 8.3 transfer that only 800lb gorillas can take
advantage of.

--- Harrison










More information about the ARIN-PPML mailing list