[ppml] Revised Policy Proposal Resource Reclamation

Stephen Sprunk stephen at sprunk.org
Mon May 7 14:17:00 EDT 2007


Thus spake <michael.dillon at bt.com>
>> As it stands, ARIN does not believe it has jurisdiction over
>> anything issued prior to its formation, so 15 years ago is
>> misleading.
>
> That is not what ARIN counsel's comments at the last ARIN
> meeting suggest.

I watched the meeting video, I've reviewed the transcript to clarify things, 
and I've been told about other conversations people have had on the topic. 
What I got out of all that is that Mr. Ryan feels that we can deny service 
to legacy holders but we _probably_ can't take space back from one who 
fights us.  He said that it's "an interesting theory" to claim escheat 
applies to abandoned number resources but hadn't had much time to think 
about it.

> If you believe this to be the case then why does your policy
> language not include this limitation?

Because we found it counter-productive to preclude a proposal which might 
change that stance.  This proposal, therefore, intentionally does not 
address the issue either way.  Absent any other policy action that passes 
muster with counsel, ARIN will continue to consider legacy space untouchable 
as it does today.

>> Also, current policy _already_ requires you to pass a review
>> of _all_ your existing space before you can get more.  If you,
>> as an ISP, are not prepared to go through that process every
>> six months when you go back for new space, you're already
>> in trouble.
>
> If you really want your policy to refer to exactly the same review
> process as for additional allocations, then why doesn't the
> policy state this in plain English.

I thought that was self-evident by making a "without cause" review a 
parallel item with a "new request" review.  Absent language that indicates 
intent to make the result different, a reasonable person assumes that the 
intent was to make the result the same.

> Nevertheless, since this policy asks ARIN to take punitive
> actions, I think it needs to first clean up vaguenesses in existing
> policy and practice. Otherwise someone can get an allocation
> and a year later be facing punitive action even though they
> have done nothing wrong.

If they've done nothing wrong, how do you propose they'll be "substantially 
not in compliance with current policy"?

The only way that should ever occur is if policy changed so significantly in 
the meantime that their original request would not have been approved (or 
even reasonably close to it).  However, a policy change that significant, 
such as I expect to see when we get close to exhaustion, would have to be 
made with the express intent of affecting past allocations and assignments 
or it'd be pointless.

>> This policy doesn't really do anything new to ISPs; it really
>> only affects end-user orgs who currently _never_ have to
>> rejustify space after they get it -- and that's where most of the
>> waste (and low-hanging fruit) is.
>
> If this policy is directed at end-users, then why does it start with the
> phrase "resources allocated or assigned to an organization."?

Because it was an attempt to get all reviews, regardless of reason or org 
type, all in one place in the NRPM and under a consistent standard/process. 
The existing text (see the sections to be deleted) is arguably worse than 
the new text as far as your arguments go, and it's not consistent with the 
RSA.

> Here you seem to be saying that addresses should flow back
> and forth between ARIN and orgs periodically, not just when
> business improves. This seems to be a rather more
> bureaucratic model of RIR like RIPE. I'm not sure that this is
> the right direction to be headed.

If the org has shrunk, or got way too much space to begin with (i.e. they'll 
never grow into it), they should give some back.  I doubt you disagree with 
either of those cases.

If the org is growing slower than expected, but will still grow into what 
they got within a reasonable timeframe, it would be a waste of time and 
effort to take back resources from them and reissue them later unless we're 
at the end game where the only way to get resources for new, properly 
justified applications is to take back older, unjustified resources.  That 
world will be ugly no matter what we do.

>> > This is fantasy. The reason audit processes exist is because
>> > of a whole range of human issues which lead to bitrot. ARIN
>> > may trust me but do they trust my data sources within the
>> > organization and all the many people who monkey with that
>> > data?
>>
>> Currently they do, unless they have reason to suspect fraud.
>> Again, that's why I termed it a "review" instead of an "audit".
>
> We need to get this IRS and fraud issue out of the discussion.
> The words used in ARIN's policies will be interpreted by ordinary
> business people and therefore, ARIN should use the meaning
> commonly accepted in the business world.

Right; I know the word "audit" has a commonly-accepted meaning and, since I 
didn't want to imply that meaning, I didn't use that word in the revised 
proposal text (though I missed editing it out of the rationale).  You are 
the one who keeps harping on it, not me.

> The word "audit" does not imply fraud. It is a common business
> term referring to a systematic review of data to verify its accuracy.

If ARIN has a reason to suspect fraud, they will audit records.  Absent 
suspicion of fraud, they will simply review your records and assume they're 
correct, i.e. that review will _not_ be an audit.  Neither of those cases is 
a change from current practice.

WRT the sections I didn't quote, I think Owen's response is sufficient.

S

Stephen Sprunk      "Those people who think they know everything
CCIE #3723         are a great annoyance to those of us who do."
K5SSS                                             --Isaac Asimov 





More information about the ARIN-PPML mailing list