[ppml] Revised Policy Proposal Resource Reclamation

[michael.dillon at bt.com]

> > The fact is that ARIN policy has never had much detail on what
> > constitutes justification for an IP address block. There is a bit
> > more detail in RFC 2050 but nowhere is there an explanation
> > of what documentation is sufficient to show "justification" or
> > what records must be kept.
> 
> I agree that's a problem.  This proposal doesn't make the situation
any
> worse than it is today.  If you're unhappy with the status quo and
think
> ARIN staff is abusing the lack of guidelines around "justification",
that
> is
> definitely within the realm of policy.  That nobody has done so in ten
> years
> tells me it's not that pressing a problem.

Don't put words in my mouth. I'm not suggesting that staff are abusing
anything. However, I am suggesting that the authors of the policy
proposal are abusing the situation. Making policy more punitive in
regards to "justification" is entirely inappropriate without first
improving the clarity around what constitutes justification.


> Reviewing someone's records (with the assumption they're correct) to
see
> if
> justification still exists and still meets current policy is an
entirely
> different thing than auditing their records to see if they're correct.
If
> you cannot see that distinction and the motivation behind it, we'll
have
> to
> agree to disagree and spare everyone else the bickering.

Since the policy gives ARIN the power to seize back number resources, I
don't think it is appropriate to do that on the basis of an informal
review. I see that the author has removed the word "audit" in favour of
"review", but I still have an issue with any punitive action being made
on such an informal basis.

> 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. If you believe this to be the case then why does your policy
language not include this limitation?

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

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. 

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

> Hint: The RSA requires you to submit anything ARIN wants at any time.
> This
> proposal is an _improvement_ since it limits how often ARIN can do
that to
> you, what your options are if they're not happy, and how much of a
grace
> period you get.

The RSA does not specify punitive actions that ARIN will take.

> You're welcome to create separate proposal on what records constitute
> "justification", which would be a complementary limit.

You're NOT welcome to propose policies which give ARIN policing powers
and allow ARIN to impose punitive measures until AFTER you fix the
policy on which you base your proposal.
 
> Because that 3/6 month supply must have been a minimum of 12 mos ago;
if
> the
> org hasn't managed to get reasonably close to the requirements that
> allocation was issued under, another few mos won't help.

In this message you have finally stated some of the assumptions on which
this proposal was based. I don't understand why you didn't do this at
the outset. 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.

> > This is a proposal to make a MAJOR change to ARIN practice.
> 
> I suggest you go read your RSA before you say that again.

Contract terms and ARIN practices are different things.

> Education might help people learn how to demonstrate their compliance,
or
> avoid asking for things they won't be able to justify, or notify
people
> about significant policy changes that could lead to resources no
longer
> being justified.  Tools would help standardize data formats and reduce
the
> cost (to both sides) of a review.  Education, of course, would also
teach
> people how to use the tools.

Bingo!
All of these are things that ARIN can and should do better. Policy can
be used to enable some aspects of this. Official suggestions can deal
with some other aspects.

> What's wrong is you're deliberately misreading things.  I said several
> times
> that I'm all for education, and even the quote you were responding to
was
> directed at members and the comment about staff was only
parenthetical.

Then why do you want to take punitive measure in an area where education
could resolve the problem. And if the education activity doesn't work,
it lays the groundwork for punitive measures that would stand up in the
courts.

> > IP addresses are virtually unlimited. IPv4 may be running low,
> > but there is a vast supply of IPv6 addresses now available.
> 
> If you really think that IPv4 and IPv6 addresses are interchangeable,
I've
> got a bridge in Brooklyn to sell you.

>From the point of view of applications, IPv4 and IPv6 are indeed
interchangeable. From the point of view of network topology, they are
also interchangeable. It isn't necessary for every org to switch new
consumption to IPv6 addresses in order to remove the pressures on IPv4
address space.

> > 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. The word "audit" does not imply fraud. It is a common
business term referring to a systematic review of data to verify its
accuracy. The word "audit" implies that there is a certain systematic
process, and a certain thoroughness to the review. It also implies that
the review goes according to some sort of plan which is considered best
practice in the business discipline (accounting, quality control, etc.).
There is a business dictionary that I found via Google which defines it
here:
http://www.businessdictionary.com/definition/audit.html

> ARIN staff know that everyone fibs a little when trying to justify a
> request, plus some percentage of that justification being subject to
bit
> rot.  Neither of those realities stop people from getting new space,
nor
> would they stop them from passing a review under the same
circumstances a
> year or three later.  In fact, it's the looseness of the term
"justify"
> that
> requires ARIN to err on the side of the member in practice.  Defining
what
> exactly it means may hurt more than it helps, depending on your
> perspective.

It's the looseness of this whole process that leads me to object to
using this as the basis for punitive action. I don't object to auditing,
per se, but because of the looseness, today and in the past, I don't
think that the audit should lead to any punitive measures.

--Michael Dillon