[arin-ppml] Policy Proposal: Customer Confidentiality

Tue Jun 9 21:13:39 EDT 2009

Aaron Wendel wrote:
> Here are some considerations I took into account.  Even though the proposal
> is only 2 sentences it's literally the 20th time I wrote it.
> 
> The policy states that the ISP may use it's address and phone number. I
> purposefully left out name.  The point of this was to show that there was a
> real entity using the block and what block they were using.  If you are
> having abuse issues with a range this will show you how extensive that range
> is so you can block/null/whatever while a resolution is sought with the ISP.
> 
> My intention with the policy is that a SWIP would have the customer's name,
> and the ISPs contact info.
> 

I don't have a problem with this.  However you don't explicitly say 
this.  You say:

ISPs may choose to enter their own address and phone number in
reassignments and reallocations in lieu of the customer's address and
phone number.  The customer's actual information must be provided to
ARIN on request and will be held in the strictest confidence.

This leaves open the question of whether the ISP can submit it's name or
the customers name in the SWIP record.  Your Rationale also talks about
"customer contact" which by definition includes the customer NAME as 
well as contact info.

In your zeal to simplify you have committed a serious error.  You have
not specified exactly what you mean, you have left it grey.  As a result
if this passes people will be claiming that they don't need to submit 
the customer name.

I would strongly suggest that if you actually WANT the customer name
and ISP contact info to show up, that you send in a policy amendment
that says this.

Ted

> Also, I used the word "may" because I wanted to leave it open to the ISPs on
> whether they use it or not.  It's an option that doesn't exist now.  If you
> choose to publish your customer list then that's up to you.
> 
> Not a perfect solution but one that I thought would serve both the privacy
> side of the argument and the abuse side.
> 
> So the request was made to me off list that I change the proposal to do away
> with SWIP and RWHOIS entirely.  I believe that they still serve a purpose
> for justification of new ranges and as a marker for how much of a certain IP
> space is allocated to a certain customer.
> 
> Aaron
> 
> 
> 
> 
> -----Original Message-----
> From: Alexander, Daniel [mailto:Daniel_Alexander at Cable.Comcast.com] 
> Sent: Tuesday, June 09, 2009 3:41 PM
> To: Aaron Wendel; arin-ppml at arin.net
> Subject: RE: [arin-ppml] Policy Proposal: Customer Confidentiality
> 
> Aaron,
> 
> You are off to a great start and have spurred good discussion. This is
> in no way a criticism of the proposal but only a related thought for the
> community to consider.
> 
> Given current policies and the proposed change, should the removal of
> section 4.2.3.7.2 (/29 requirement) be included in such a change? Is
> there a point of having hundreds of thousands or millions of /29's,
> /28's, etc. with "private customer" and "private address" or the ISP
> address information in whois? 
> 
> Is there any reason to have all the more specifics listed in whois if a
> single aggregate record would cover the same address and POC
> information? Of course if an end user wants the more specific listed
> with different details, they should be allowed to do so. It just seems
> that whois is getting cluttered with specifics that provide no
> constructive use that would not be covered by the parent record.
> 
> Dan Alexander
> ARIN AC
> 
> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Aaron Wendel
> Sent: Tuesday, June 09, 2009 3:34 PM
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Policy Proposal: Customer Confidentiality
> 
> I purposely wrote the policy to be short, to the point, and easy to
> understand.  The customer's communication with their provider should
> include
> whether they want their personal information published in a publically
> accessible database.
> 
> My point in writing this policy was to protect information that is
> proprietary to any business.  Tell a realtor you know that you're
> thinking
> about going into real estate and you'd like his customer list. Then tell
> him
> that you actually need his customer list to make sure he's legit.  If
> all he
> does is laugh at you then you got off lucky.  I can think of no other
> private business that is required to publish customer information to the
> public.
> 
> Customers can ask to have their information included and many of ours
> specifically do but many of them have no idea how to admin their own
> networks.  That's why they come to us.
> 
> This is my first policy proposal and the first I've seen from a source
> outside the usual suspects you see bating around the proposals on the
> list.
> I am not sure how to change the wording or if it needs changing but I
> feel
> this is an important issue and am open to suggestions and guidance on
> changes that people feel need to be made to make this a workable policy.
> 
> Aaron
> 
> 
> 
> -----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. 
> 
>> -----Original Message-----
>> It makes it possible for third parties to perform spot-checks which
>> audit the ISP's honest use of address space. Whether used or not, this
>> greatly impacts ARIN's process transparency. This is especially
>> helpful when a supposed ISP is suspected of fraud. A name alone or
>> fully private registrations are insufficient for auditing.
>>
>> Regards,
>> Bill Herrin
>>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.