[arin-ppml] Policy Proposal: Customer Confidentiality

[Steve Bertrand]

Kevin Kargel wrote:
>> -----Original Message-----
>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
>> Behalf Of Milton L Mueller
>> Sent: Tuesday, June 09, 2009 1:36 PM
>> To: 'William Herrin'
>> Cc: arin-ppml at arin.net
>> Subject: Re: [arin-ppml] Policy Proposal: Customer Confidentiality
>>
>> I don't understand how this is a consideration if the ISP continues to be
>> accurately identified in the whois. I don't understand how a third party's
>> suspicion of an ISP gives them a right to access a customers' data as
>> opposed to the ISP data. Recall that ARIN has access to the customer
>> information and would thus be accessible to any real fraud investigation.
> 
> To my mind the issue is not one of fraud investigation but one of abuse
> resolution.  It is all too easy for a network host to broadcast a number of
> types of storm traffic from innocent causes such as hardware or software
> failure or mis-configuration.  Even things as simple as routing loops can be
> debilitating to more than the end user in question.
> 
> The end user need not be identified, but a contact to an administrator who
> can deal with routing and traffic issues should be required.
> 
> I am all for privacy, but reachability of an effective PoC needs to be
> maintained.  A PoC who calls a contact who relays a message to someone who
> knows who the administrator is cannot be effective.

I agree with what Kevin is saying here.

In reality, if we can simply publish our own contact info in the SWIP
records, then why bother publishing SWIP information at all? My
aggregate block already has our contact info, so why take the time to
publish further info about smaller pieces of our space with the exact
same information?

The only reason I can see a privacy card being played would be in
sensitive services (military etc). Even in that case, the space could be
swip'ed to an individual responsible for the network.

I think that if something like this is to be ratified, it should focus
solely on privacy from a safety and security standpoint, and not out of
speculation of potential lost business.

Steve

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3233 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090610/a2952fb8/attachment.bin>