[ppml] Revised Policy Proposal Resource Reclamation

[Stephen Sprunk]

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

And I changed my position on those three proposals for the same reason. 
Education, communication, tools, etc. are not "number resource policy". 
Those things belong to the ACSP.  However, you're definitely welcome to 
float policy proposals in this direction and see what the AC and BoT say.

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

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

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.

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

As it stands, ARIN does not believe it has jurisdiction over anything issued 
prior to its formation, so 15 years ago is misleading.

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

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

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.

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

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

I'd be happy with 12 or even 24 months; in fact one staffer has already
suggested that to me privately.  If that were the only thing stopping people 
from supporting the proposal, either Owen and I could revise it or the AC 
could adjust the number during last call.  Also, the proposal specifically 
says that ARIN will work with any reasonable request for a longer duration.

> Why isn't it tied to the last allocation period, i.e. did they ask for
> a 3 or 6 month supply?

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.

Also, not all resources issued are allocations, and not all allocations are 
tied to a 3/6 month window.  By leaving it to "compliant with current 
policy", a huge variety of situations can be handled.  Not everyone is an 
ISP.

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

No, it says that return or revocation is immediate for _billing_ purposes. 
That doesn't mean it doesn't show up in WHOIS or isn't officially connected 
to the org during the renumbering period, just that they don't have to pay 
for it since it's going away.

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

Just because you fear something doesn't mean it's nonsensical or a waste of 
time.

> This is a proposal to make a MAJOR change to ARIN practice.

I suggest you go read your RSA before you say that again.

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

It was.  Just because those several people don't agree with you doesn't mean 
their time and effort was a waste.  Don't worry; you have six months until 
the next meeting to try to convince others that the idea is flawed, offer a 
counter-proposal, or politely suggest changes that address your issues with 
the current one.

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

Either an org's resources are justified under current policy or they aren't. 
There is absolutely nothing ARIN can do to change that.

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.

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

If counsel thinks there's a problem, we'll fix it or withdraw it.  Owen and
I both respect Mr. Ryan and will make whatever changes we need to to address 
his concerns.

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

Of course it's okay for a company to educate its employees.

> but not OK to do the same for ARIN members? Something is
> wrong here.

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.

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

If you really think that IPv4 and IPv6 addresses are interchangeable, I've 
got a bridge in Brooklyn to sell you.

> Here again, ARIN is failing its charter because it is not taking
> its education role seriously.

Check the PPML archives.  I asked the BoT to do more outreach about IPv6 and 
the response was it was against the charter.  Don't waste your time yelling 
at the people who are on your side.

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

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.

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