[arin-ppml] Comments on Draft Policy 2010-3: Customer Confidentiality
cgrundemann at gmail.com
Wed Apr 7 12:13:05 EDT 2010
On Wed, Apr 7, 2010 at 09:29, Chris Engel <cengel at sponsordirect.com> wrote:
> I agree with Jay 100% here. For people that WANT to anonymize thier information (whether for fair reasons or foul) thier going to be able to put in bogus information here regardless of policy. Unless you want to start investing about $10,000 per registration to actualy investigate whether the information that they provide is accurate, then anything you write as policy isn't going to help here.
You are right, this policy will not help. What might is an opt-in type
email once a year to all (technical and abuse) POCs. See the
adopted-but-not-yet-implemented policy 2008-7 for an idea of what this
> For anyone else, it really should be between the ISP and the customer as to who gets listed. Totaly ignoring the privacy issue...a policy like this would actualy allow for faster response to problems in many cases. As Jay pointed out, many companies may not even have some-one technical on staff that can deal with these issues. If you call up a receptionist on the phone, they aren't likely to be able to help you....and if they are even mildly tech saavy they aren't going to be able to tell the difference between you and some-one making a social engineering attempt on them.
Even if you are right, this policy (2010-3) is _not_ needed to
accomplish this. ARIN already allows simple reassignments which use
the upstream POC information. Quoting from
* IPv4 Reassign-Simple
Used to sub-delegate IP addresses to a customer that does not need to:
* sub-delegate the addresses to their own customers
* maintain their own in-addr.arpa delegation
* display their own point of contact (POC) information.
Can also be used to change the customer name and address information
(but not the range) on an existing simple reassignment and to remove
simple reassignments. It is submitted by the parent organization's
Administrative or Technical POC, or the Technical POC for the
POCs are not associated with simple reassignments. The customer
receiving the reassignment will have the assigning ISP's POCs and name
> Even for organizations that DO have technical people on staff....very few maintain 24/7 NOC's like ISP's do. I know for our organization if you try to contact any of our publicaly listed numbers outside of regular business hours, you won't get a response. However, our hosting providers and customers do have call sheets with after hours emergency contact numbers on them.... and I'd certainly be willing to provide something similar to an ISP's NOC or other trusted agent that can act as a gateway function between some-one with a legitimate issue...and some-one trying to sell me hosting space in Hong Kong. Tell me, which would yeild a faster response?
The question here should not be "what happens in this one corner case"
or "what happens in my one example" but rather "what does the best
good for the entire community - in all cases?"
The answer is that the most complete, comprehensive and valid whois
directory possible provides the best possible resource for *all*.
> Respectfully to the security research organizations, why should you not have to justify your legitimate need for such information? Aside from technical considerations and on to ethical/public policy issues. Information access should be a 2 way street. If you want access to some-one elses information then you should be prepared to surrender your own in order to get it. You should be able to justify your access to that information and there should be some method of transparency/tracking/accountability as to what you do with that information. Right now, WHOIS is about as far away from a 2-way street as you can get. The information contained in WHOIS may not be particularly sensitive... but the principle remains the same.
I believe in an Open Internet. Walling off whois data is not conducive
to openness. OTOH, fully available whois data has very little
downside, quite a lot of upside and _is_ conducive to keeping the
Internet ecosystem Open.
To restate: I am opposed to dp 2010-3.
I again invite those in favor of this policy to review pp 109 which
just might meet your needs without creating the problems that this
> Christopher Engel
> 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:
> Please contact info at arin.net if you experience any issues.
More information about the ARIN-PPML