[gnso-rds-pdp-wg] ICANN Meetings/Conversations with Data Protection and Privacy Commissioners
Stephanie Perrin
stephanie.perrin at mail.utoronto.ca
Tue Oct 17 13:27:18 UTC 2017
Where people have a right in law to privacy, you cannot charge them to
actually put those rights in place.
Stephanie Perrin
On 2017-10-16 15:43, John Bambenek via gnso-rds-pdp-wg wrote:
>
> 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
>>>>
>>>>
>>>> *FollowLegitScript*: 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
>>
>
>
>
> _______________________________________________
> gnso-rds-pdp-wg mailing list
> 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/20171017/9405ca00/attachment-0001.html>
More information about the gnso-rds-pdp-wg
mailing list