[ppml] Revised Policy Proposal Resource Reclamation

[michael.dillon at bt.com]

> Unfortunately, helping people and developing tools are not policy
matters.

I strongly disagree on that point. I certainly don't want to see policy
which goes into too much detail on such things, but I think that it is
entirely appropriate for ARIN policy to specify broadly what type of
educational activities ARIN should engage in, as well as what sort of
tools it should develop. For instance, I supported the broad thrust of
the PGP policy which directed ARIN to build tools so that communications
with ARIN could be authenticated with PGP.

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. This is very different from NANPA who allocate blocks of
telephone numbers and who not only have specific documentation
requirements, but don't really need to audit much since orgs must submit
regular reports on their actual utilisation complete with estimated
runout dates.

> The intent is that the same records would be used in a review that
would
> be
> used in any request for an allocation or assignment today.  If you
don't
> have them, then you shouldn't have been able to get those resources in
the
> first place unless it was a long, long time ago and you've never asked
for
> anything new since.

People misplace old documents, especially when a role travels from one
employee to another. And acquisitions happen. And systems are obsoleted
and replaced. And many companies require old documents to be
destroyed/deleted unless they meet certain criteria. If the ARIN contact
for an org tells their management that records must be kept, and
management doesn't see a business case for doing so, AND THERE ARE NO
ARIN POLICIES DETAILING WHAT RECORDS MUST BE KEPT, then bitrot sets in.
The fact that a database exists and has lots of records in it, doesn't
mean that the data continues to be valid. Most companies go through
regular cycles of data cleansing to clean out crud and correct errors
but these often never get more than 80% done before something else takes
priority.

> Except in cases where ARIN has cause to suspect fraud, they would
trust
> that
> you're not lying (much), just as they do today.  I avoided using the
term
> "audit" because that implies having to prove your records are correct
> (e.g.
> to the IRS).

Audit is a general accounting term totally unrelated to the IRS. It
refers to the process of crosschecking records looking for
inconsistencies that would indicate someone is falsifying data or
siphoning off money etc. It is a perfectly valid term to use in a policy
which asks ARIN to check a company's records to make sure that
JUSTIFICATION for an address block continues to exist.

> org has to produce records sufficient for ARIN to complete the review,
and
> if they don't have them, they need to generate them.

This is what I object to. I strongly object to ARIN contacting me and
demanding that I show justification, not just for 6 months supply of
addresses, but 15 years or so. 

I would object less to a policy which defines the records that I must
keep on hand, and mentions, in one clause, that ARIN can request me to
submit these defined records at any time. If I know in advance, what
records I need to submit, then I can start sorting out data cleanliness
issues today, long before anyone asks for the records. If ARIN policy
defines the records that I must keep, then I can more easily make an
internal business case for any system and process changes necessary to
do this right. It's not that I can't reverse engineer the network and
get this info, its just that said reverse engineering is time consuming
and its harder to spread the workload. 

Even in a small organization, where everything is in a folder full of
spreadsheets, they run into bitrot and data cleanliness issues.

> The proposed grace period gives them time to renumber.

The grace period is not stated as a time for the org to renumber but as
a waiting period for ARIN before reissuing the addresses. Why isn't it
12 months like in 4.6 Amnesty requests. Why isn't it tied to the last
allocation period, i.e. did they ask for a 3 or 6 month supply? There is
a similar situation with the LIRs customers. When a customer moves to
another ISP, they are supposed to return and renumber. Not only does
4.2.3.3 not specify 6 months, it doesn't mention any specific time
period. Why doesn't this proposal fix that? Also, the customer does not
have to return the block until after the renumbering period, but the
proposal asks ARIN to pull back the block from the LIR first, before the
renumbering period.

These kinds of flaws show that very little thought went into this
proposal an almost no effort was made to make it fit into the set of
existing policies. These kinds of proposals don't make any sense and I
can't figure out what the point is of submitting them, other than to
waste our time. This is a proposal to make a MAJOR change to ARIN
practice. Such a proposal should not even be submitted before it is
vetted in detail by several people. By "in detail" I mean that they
suggest a lot of changes and adjustments that show they did more than
spend 5 minutes scanning the proposal. And the proposal needs to be
checked against the entire existing policy set to find out where there
are mismatches, gaps, etc.

> > ... I believe that ARIN's role here has to be in helping an org
> > reach compliance, not in punishing an org or pulling the rug out
> > from under them.
> 
> ARIN cannot help an org reach compliance.  ARIN could, however, help
them
> prove they were in compliance.  There's a serious difference there.

If ARIN would use the education hat to deal with this issue, then they
could indeed help an org reach compliance. I'm not asking them to send
out free consultants to spend a week in your office.
 
> ARIN has policy on what justifies an allocation/assignment.  It has
> changed
> slowly over time, but not so much that someone still assuming rules
from
> five years ago is likely to be in trouble today.  

Where is it defined so clearly that ARIN can be confident they will not
be sued if they claim that an org no longer "justifies" their
allocation? The policy does not have to be written in a way that
attracts lawsuits.

>  I
> think it's best to get people (including staff!) used to the idea of
> reviews, what documentation they'll need, etc. now while they're still
> highly likely to pass.

So you believe that it is OK to provide documentation and education to
staff but not OK to do the same for ARIN members? Something is wrong
here.

> The charter requires stewardship.  We would be irresponsible stewards
if
> we
> did not verify the need of people consuming a limited resource that
others
> _can_ justify a need for.

IP addresses are virtually unlimited. IPv4 may be running low, but there
is a vast supply of IPv6 addresses now available. Here again, ARIN is
failing its charter because it is not taking its education role
seriously. Almost all the people involved, from staff, to BoT to AC to
member contacts, have been in this business too long and are being
blindsided by changes to the environment in which we all function. What
we have here is a failure of the imagination. Read the report on 9/11
and the Challenger disaster to see what happens when people get
complacent and stuck in their ways. Tradition does not work well in the
modern world.

> See above.  Even the simple but highly popular idea of a web
interface,
> which presumably would show all the resources an org has and what
they're
> tagged for, would be a step in the right direction.  If the tools
existed,
> we could force people to use them, but we can't use policy to create
them
> out of thin air.

I would build the tool myself and give it away if I only knew what
darned data it NEEDS to have in it. And if that data spec was truly
based on need-to-know, not corporate espionage requirements or someone's
fantasy of big-brother watching for the evil spammers. Of course, we are
really talking about publishing data to a few ARIN employees who work
behind a chinese wall, not to the whole world, so I may be somewhat more
lenient, but I still believe that the data spec must be based on what
ARIN needs to know in order to justify an assignment from my allocation.

> ( In fact, a tool could be made to check compliance status; a review
would
> merely consist of ARIN looking at the tool and, if the report wasn't
> positive, asking the org to make sure their data is up to date. )

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? 

--Michael Dillon