[gnso-rds-pdp-wg] ICANN Meetings/Conversations with Data Protection and Privacy Commissioners

John Bambenek jcb at bambenekconsulting.com
Mon Oct 16 19:43:00 UTC 2017


Exactly what is the impracticality of not charging people for not
listing their information in WHOIS? Many registries do this today. Some
registrars / ccTLDs operate this way by default.

The only difficulty is setting the fees for the service to cover the
costs of offering said service. Businesses do this everyday.

Am I missing something?

On 10/16/2017 12:37 PM, David Cake wrote:
> I do not think that other people know what you need to do your job as
> your currently do it. 
>
> It is plain that the intent of the GDPR is to change existing
> practice. You have suggested sweeping changes to the way other people
> practice their businesses (such as mandatory privacy protection for
> free), they have said those changes are impractical. You have
> resolutely claimed that significant changes to the way you do your
> work are not only impossible, but so self-evidently so that all we
> really need to do is to explain to the DPAs that it is important that
> you not have to change. There is, as yet, no evidence whatsoever that
> this is a likely outcome. 
>
> I do accept that fighting abuse is a worthy endeavour. I also think
> there are multiple forms of abuse, some of which will be significantly m
>
> If you accept that the law is unlikely to be changed or vetoed
> significantly explicitly to support the work you do, then we can move
> on to considering compromises that might make that practical, such 
>
>> On 29 Sep 2017, at 6:18 am, John Bambenek via gnso-rds-pdp-wg
>> <gnso-rds-pdp-wg at icann.org <mailto:gnso-rds-pdp-wg at icann.org>> wrote:
>>
>> I want to me too this... this is the single biggest cause of the
>> contention in this group. I am being told by people who don't do
>> anti-abuse or investigations on what I need to do my job and when I
>> tell them what I need to do my job, my opinion doesn't matter.
>>
>> **We** are the experts in this field. It'd be nice when people are
>> talking about what is needed to fight abuse, we at least consider the
>> opinions of people that **actually fight said abuse**.
>>
>> And we will be taking this message to the DPAs directly so they
>> understand what's at stake.
>>
>>
>> On 09/28/2017 05:10 PM, John Horton wrote:
>>> Chuck, let me briefly (I hope briefly) weigh in in response to that. 
>>>
>>> My observation is that the group does agree that fighting abuse is a
>>> worthy endeavor -- I suspect you'd get unanimity on that point. My
>>> sense is that where there's disagreement may be on two points:
>>>
>>>  1. Whether anti-abuse types really need a Whois record of the
>>>     domain name in question to fight abuse -- the argument has been
>>>     made that Whois is so often falsified, or privacy-protected,
>>>     etc. that Whois isn't _really_ useful to anti-abuse types, and
>>>     that there are more useful tools than Whois. 
>>>  2. Whether the entire Whois data set (or, say, even 95% of it), and
>>>     being able to reverse query against it, is useful to anti-abuse
>>>     types. 
>>>
>>> From my perspective, I do think that there are a few folks in this
>>> working group who, even when I or others have repeatedly insisted
>>> that (and provide examples of how) we genuinely need 1) Whois
>>> records on specific merchants or bad actors, and 2) need the entire
>>> corpus against which to reverse query, seem unwilling to take our
>>> representations and examples at face value. I guess I've become a
>>> little cynical as to whether, even if that argument is presented
>>> objectively and compellingly, working group members are willing to
>>> be persuaded of it or not. 
>>>
>>>
>>>
>>> John Horton
>>> President and CEO, LegitScript
>>>
>>>
>>> *Follow LegitScript*: LinkedIn
>>> <http://www.linkedin.com/company/legitscript-com>  |  Facebook
>>> <https://www.facebook.com/LegitScript>  |  Twitter
>>> <https://twitter.com/legitscript>  |  _Blog
>>> <http://blog.legitscript.com/>_  |  Newsletter
>>> <http://go.legitscript.com/Subscription-Management.html>
>>>
>>>
>>>
>>> On Thu, Sep 28, 2017 at 2:51 PM, Chuck <consult at cgomes.com
>>> <mailto:consult at cgomes.com>> wrote:
>>>
>>>     I could be wrong but I think that we need to first convince
>>>     ourselves as a
>>>     working group that fighting abuse is a critical and essential
>>>     need and I
>>>     don't think that should be hard to do.  A lot of you have made
>>>     very strong
>>>     arguments in that regard and I believe that we have already
>>>     agreed that
>>>     fighting abuse is a legitimate purpose for at least some RDS
>>>     elements.
>>>
>>>     Note WG agreement #11: "Criminal Investigation & DNS Abuse
>>>     Mitigation is a
>>>     legitimate purpose for "Minimum Public Data Set" collection." 
>>>     We obviously
>>>     have to get beyond the MPDS and we will.
>>>
>>>     It seems to me that the following WG agreement, although not
>>>     directly
>>>     related to abuse mitigation, sets a basis upon which we can further
>>>     deliberate the abuse mitigation purpose: " 17.  A purpose of RDS
>>>     is to
>>>     facilitate dissemination of gTLD registration data of record,
>>>     such as domain
>>>     names and their domain contacts and name servers, in accordance with
>>>     applicable policy."  I admit that there is a lot of work we must
>>>     do to
>>>     develop requirements and ultimately policies to allow and
>>>     support the use of
>>>     RDS data for abuse mitigation purposes but we can do that.
>>>
>>>     I think all of the following recent WG agreements indirectly
>>>     support further
>>>     deliberation on the abuse mitigation purpose:
>>>     " 30. At least one element identifying the domain name
>>>     registrant (i.e.,
>>>     registered name holder) must be collected and included in the RDS.
>>>     31. Data enabling at least one way to contact the registrant must be
>>>     collected and included in the RDS.
>>>     32. At a minimum, one or more email addresses must be collected
>>>     for every
>>>     domain name included in the RDS, for contact roles that require
>>>     an email
>>>     address for contactability.
>>>     33. For resiliency, data enabling alternative or preferred
>>>     method(s) of
>>>     contact should be included in the RDS; further deliberation to
>>>     determine
>>>     whether such data element(s) should be optional or mandatory to
>>>     collect.
>>>     34. At least one element enabling contact must be based on an
>>>     open standard
>>>     and not a proprietary communication method.
>>>     35. To improve contactability with the domain name registrant
>>>     (or authorized
>>>     agent of the registrant), the RDS must be capable of supporting
>>>     at least one
>>>     alternative contact method as an optional field.
>>>     36. Purpose-based contact (PBC) types identified (Admin, Legal,
>>>     Technical,
>>>     Abuse, Proxy/Privacy, Business) must be supported by the RDS but
>>>     optional
>>>     for registrants to provide.
>>>     37. The URL of the Internic Complaint Site must be supported for
>>>     inclusion
>>>     in the RDS.
>>>     38. The Registrar Abuse Contact Email Address must be supported for
>>>     inclusion in the RDS, and must be provided by Registrars.
>>>     39. Reseller Name MUST be supported by the RDS. Note: There may
>>>     be a chain
>>>     or Resellers identified by Reseller Name.
>>>     40. Per recently-approved consensus policy on consistent
>>>     labeling and
>>>     display, BOTH the Registrar Abuse Contact Email and Registrar
>>>     Abuse Contact
>>>     Phone must be supported for inclusion in the RDS, and MUST be
>>>     provided by
>>>     Registrars.
>>>     41. In the interest of maximizing contactability, additional
>>>     contact methods
>>>     MUST be supported by the RDS as an open-ended list and be
>>>     optional for
>>>     Registrants to provide. This does not preclude agreements on
>>>     requirements to
>>>     include other contact methods.
>>>     42. The RDS must support Registrant Postal Address data
>>>     elements: Registrant
>>>     Street Address, City, State/Province, and Postal Code.
>>>     43. The RDS must support Registrant Phone + Registrant Phone Ext
>>>     (extension)
>>>     data elements "  I call this one out in reaction to some
>>>     discussion on the
>>>     WG list today about identification of the domain name registrant."
>>>     These may not go far enough for some but they provide a start
>>>     that we can
>>>     build on.
>>>
>>>     Chuck
>>>
>>>     -----Original Message-----
>>>     From: gnso-rds-pdp-wg-bounces at icann.org
>>>     <mailto:gnso-rds-pdp-wg-bounces at icann.org>
>>>     [mailto:gnso-rds-pdp-wg-bounces at icann.org
>>>     <mailto:gnso-rds-pdp-wg-bounces at icann.org>] On Behalf Of theo geurts
>>>     Sent: Thursday, September 28, 2017 11:07 AM
>>>     To: Andrew Sullivan <ajs at anvilwalrusden.com
>>>     <mailto:ajs at anvilwalrusden.com>>; gnso-rds-pdp-wg at icann.org
>>>     <mailto:gnso-rds-pdp-wg at icann.org>
>>>     Subject: Re: [gnso-rds-pdp-wg] ICANN Meetings/Conversations with
>>>     Data
>>>     Protection and Privacy Commissioners
>>>
>>>     Hello Andrew,
>>>
>>>     1 I agree you need to be specific, but also you should ask,
>>>     would a DPA
>>>     accept it? Regardless if that is a DPA in Europe or China or
>>>     Jamaica.
>>>     Setting the baseline to the GDPR would be a mistake, these data
>>>     protection
>>>     laws are always in motion. As such you need to implement data
>>>     protection
>>>     principles when you define purpose. Did we really do that?
>>>
>>>     2 I am not sure if there is a misapprehension. I do think we did
>>>     not go out
>>>     of the box far enough. We somehow keep circling back to the
>>>     WHOIS, and that
>>>     is somewhat strange given the composition of the WG.
>>>     We did put a ton of work into looking at the current data
>>>     elements and all
>>>     that, but we never into the concept of no WHOIS/RDS and come up
>>>     with a
>>>     solution in such a scenario.
>>>
>>>     If we want to convince these policymakers of what we are facing
>>>     abuse wise,
>>>     we must do better.
>>>
>>>     Theo
>>>
>>>
>>>     On 28-9-2017 19:11, Andrew Sullivan wrote:
>>>     > On Thu, Sep 28, 2017 at 06:46:29PM +0200, theo geurts wrote:
>>>     >> I think it is meant that IP addresses will be considered personal
>>>     >> information under the GDPR, that concept might be new to
>>>     folks in this
>>>     WG.
>>>     > I _know_ that.  But there are two issues here:
>>>     >
>>>     >      1.  It appears entirely clear, both from previous
>>>     discussions and
>>>     >      from the legal analysis that was just delivered, that
>>>     collection
>>>     >      of certain data (and we're still talking about collection,
>>>     >      remember) is permitted if you have legitimate purposes.
>>>     >      Therefore, we should be paying attention to those
>>>     purposes, and be
>>>     >      specific about it.
>>>     >
>>>     >      2.  It is possible that any law, or any interpretation of
>>>     the law,
>>>     >      is being made with a misapprehension of how the Internet
>>>     actually
>>>     >      works.  Quite frankly, it is apparent to me that an alarming
>>>     >      number of policymakers have a deeply mistaken model for
>>>     the way
>>>     >      the Internet works, mostly aligned with a picture that
>>>     looks like
>>>     >      the way the phone system used to work.  But we have to
>>>     make policy
>>>     >      for the actual Internet, rather than for some system that
>>>     does not
>>>     >      actually exist.  This is why I sent that note the other
>>>     day about
>>>     >      figuring out what we want and then asking lawyers how
>>>     that can be
>>>     >      made to comport with such legal regimes as we know,
>>>     rather than
>>>     >      doing it the other way.
>>>     >
>>>     > Best regards,
>>>     >
>>>     > A
>>>     >
>>>
>>>     _______________________________________________
>>>     gnso-rds-pdp-wg mailing list
>>>     gnso-rds-pdp-wg at icann.org <mailto:gnso-rds-pdp-wg at icann.org>
>>>     https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
>>>     <https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg>
>>>
>>>     _______________________________________________
>>>     gnso-rds-pdp-wg mailing list
>>>     gnso-rds-pdp-wg at icann.org <mailto:gnso-rds-pdp-wg at icann.org>
>>>     https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
>>>     <https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> gnso-rds-pdp-wg mailing list
>>> gnso-rds-pdp-wg at icann.org
>>> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
>>
>> _______________________________________________
>> gnso-rds-pdp-wg mailing list
>> gnso-rds-pdp-wg at icann.org <mailto:gnso-rds-pdp-wg at icann.org>
>> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20171016/cbe10fc5/attachment-0001.html>


More information about the gnso-rds-pdp-wg mailing list