[arin-ppml] Policy Proposal: Customer Confidentiality

Tue Jun 9 19:29:51 EDT 2009

I think this message has a few important points that are being missed in 
this discussion:

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

BTW, thank you for taking the trouble to be precise about language.  It 
really helps to have a short, precise, and concise proposal.

> 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 think this is a very important point.  To paraphrase, it means that a 
company still has to publish details about what downstream organizations 
have received address space.  That is an important requirement to 
preserve, IMO.  It also makes it possible to check how much space a 
given prospect/customer has from other providers (if you're an ISP 
evaluating an IP space request from that customer).

I support encouraging ISPs to put in the best contact information 
available, whether it points to the end customer or the ISP. 

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

I think this proposal strikes a good balance between a number of 
competing requirements, and plan to support it.

-Scott

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