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

[Martin Hannigan]

Harrison,

I appreciate the thought that you put into your reply. Inline.

On Sat, Jun 9, 2012 at 7:32 PM, Astrodog <astrodog at gmx.com> wrote:
> 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

I agree, although I continue to assert that they aren't relative to
these proposals.

> 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

I am not defining a special class. ARIN has already done that. The
definition is already in the LRSA and the bankruptcy disadvantage that
we repeatedly observe underscores that this is a fact already.

> 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.

I'd need to wait for the legal review to ascertain if that was
actually a problem, but it could be fixed it if is.

>
> 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.


True, but if another RIR is willing to accept a /28 and their members
peers are willing to listen to it, why not? We also learned a lesson
from a global policy round where the RIR's appreciate it when you
don't set their standards. Defining a minimum allocation unit for them
seems unnecessary.

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

Yes. I think that we should treat all legacy space equal, bankruptcy or not.

>
> 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.


The overhead should be borne by the parties transferring the resource.
I would think that this is already the case, that ARIN asks for the
chain of custody rather than create it themselves.

>
> 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.

As much as I dislike vague language in the NRPM, this seems to be one
proposal where it is somewhat useful. I am not advocating for evicting
users of addresses. I'm ok encouraging them to make a deal with the
rightful holder and if they can't then being "evicted" from the space.

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

I'm not sure how ARIN can execute an LRSA with an unauthorized party
unless they are already doing some validation. I'm not sure that this
is bad to be honest.

> 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

In the case of bankruptcy, there is *always* someone that will pick up
the forgotten scraps athough I do not know if there is a statute of
limitations on creditor claims. I would leave that to ARIN to
determine as part of implementation. If someone picked the resources
up off of the floor of an entity that simply opted to go out of
business, I do not believe that they are the rightful holder of the
resources. But the law might. If so, that will be the case, but that
is something that is a legal issue, not policy.


> 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.


I'm sure that can be dealt with from a legal perspective.

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

You'd have to wait until legal review so perhaps not opposing it until
a later stage would be helpful.


Best,

-M<