[gnso-rds-pdp-wg] ICANN Meetings/Conversations with Data Protection and Privacy Commissioners
John Bambenek
jcb at bambenekconsulting.com
Tue Oct 17 17:00:36 UTC 2017
ICANN is US-based and the gTLDs we care about are owned by US
companies... I don't even have to take extraterritoriality for a ride to
get what I want.
On 10/17/2017 08:27 AM, Stephanie Perrin wrote:
>
> 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
>>>>>
>>>>>
>>>>> *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
>>>
>>
>>
>>
>> _______________________________________________
>> 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
> 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/6ce5c27f/attachment-0001.html>
More information about the gnso-rds-pdp-wg
mailing list