[ppml] Policy Proposal 2006-1: Residential Customer Privacy

> My perception was that most (certainly not all, but most) of the 
> opposition to 2006-1 voiced in Montreal was about ARIN's operational 
> needs not being met -- I think we had a rough consensus that doing 
> some partial-postal-code thing was not such a good idea.  My previous 
> post talks about bit more about the operational concerns raised by 
> ARIN staff.

This is the bit that confuses me. Why is a policy
proposal messing around with ARIN's operational
model?

Clearly, ARIN has a need for detailled address utilization
information in order to perform its basic functions. And
ARIN is ready and willing to sign an NDA with any 
applicant who has concerns about the sensitivity of
the data that they submit. They even operate a Chinese
wall internally so that, for instance, managers do 
not have access to this data.

Applicants regularly submit detailed network diagrams
and maps, purchase orders, client lists, inventory
records, spreadsheets, databases and all manner of
information to show that they are indeed building out
a network of the magnitude that will justify the number
of addresses they are requesting. Or to show that they
really did use up the addresses that they got.

This policy suggests changing a section of policy
that applies only to ISPs. It obfuscates this behind
the NPRM section number 4.2.3.7.6 which refers to
IPV4, Allocations to ISPs, Reassigning Address Space 
to Customers, Reassignment Information, Residential
Customer Privacy.

If you examine the NPRM you will notice that there
is another section entitled Directory Services that
deals with some aspects of whois data. Then, going
to 4.2.3.7 you will see that it *MIXES TOGETHER*
references to the data needed by ARIN operationaly
and the data published by Directory Services using
whois and rwhois protocol. 

To begin with, this is bad, bad policy. It is confusing
to read, mixes up internal operational issues with 
external public policy issues, and it does not have
any published rationale for its existence. Secondly,
picking nits with bad policy, such as is done in
proposal 2006-1, is not the way to fix this thing.
It only adds to the confusion because different
sets of edits to this confusing section are made
based on different basic premises.
http://www.arin.net/policy/proposals/2006_1.html

Nevertheless, I would vote in support of this policy
change because it does allow the entire address to
be suppressed and that is a good thing. I would hope
that any ARIN members assigning to residential sites
already suppress the address anyway regardless of the
flawed policy.

But, we need to go much further than this. To start
with, any ARIN operational needs must be separated
from Directory Services. Then, we need to define a
clear scope for Directory Services. It is widely known
that the whole model is broken and has been broken
since the advent of the commercial Internet over 10
years ago. We need an up to date definition for
the scope and purpose of ARIN's whois directory
service. It needs to specifically meet the needs 
of network operations people and nothing more.
In particular, ARIN is not obliged to support
vigilante groups, private investigators, stalkers,
or even law enforcement in its published whois
directory. If law enforcement needs data, they
can always get it under subpoena wherever it may
be whether in ARIN's hands or an ISP's.

If we go back to network operational realities,
the main requirement for a whois directory is so
that when network problems occur, for whatever reason,
a netops person can contact a responsible person in
another organization's network operations department.
To that end, it makes sense to only publish information
for those people who voluntarily request it with one
exception, that any organization receiving an ARIN
allocation MUST publish at least one working contact
point.

--Michael Dillon