[gnso-rds-pdp-wg] Notes from today's RDS PDP WG meeting

Thu Sep 22 23:53:02 UTC 2016

I absolutely agree with Volker on the last three points.  We absolutely have a mandate to examine what data is made available now - and WHETHER IT SHOULD BE AVAILABLE in the future.  The fact is, laws that were not in place when the Whois protocol were developed about data protection are now in place for many jurisdictions now. And that means that, in those jurisdictions, access to registrant data that was okay in the past is now illegal.  Yes, it makes things more difficult for some, but the argument that ease of access to data would be more difficult for some does not stack up against the reality global legislation that access to that data should be, at best, restricted or denied. So the mandate is not about who is facing more difficulties;  it is about a changed environment in which data protection laws redraw the maps of who should have access to what data.

Holly
On 23 Sep 2016, at 1:46 am, Volker Greimann <vgreimann at key-systems.net> wrote:

> Even though we are out of scope of the current discussion, I feel the need to disagree.
>> I would strongly object to any of those items being characterized as "content."  And even if they were "content," that is not a per se exclusion in any way.
> We need to differentiate between two things: Abuse by use of the domain name in itself and abuse by use of additional services, such as mail or hosting. The latter is content, not related to the registration itself.  In most cases, domain names are abused to facilitate content-based abuse, but the abuse lies in the further use, not the use of the domain name in itself. 
> I personally feel that these forms of a buse are better dealt with at the level of the service provider used for the actual abuse, but that is another story and shall be told another time.
> 
>> Many, if not most, threats to security and other forms of abuse involve both the registration of a domain name and the use of that domain name in some fashion.  It's clear and critical that we need to allow for elements of use to be included in the purposes for which RDS data is used.
> Registration data of a domain name has no immediate connection to its use.
> 
>> This work is done now, regularly and successfully, using WHOIS data among other things.  We have no mandate to restrict these uses (and as Greg A. notes, we're at a point where discussion of restrictions are premature).
> Actually, we do have that mandate. Our mandate is to take the EWG work and use it to build a new model of registration data collection, storage and access that is complianct with all relevant laws and legel requirements and provides the ability for those legitimate needs to access that data that they are legally entitled to access using the legally required means to access that data (say, a court order).
>> 
>> As a final note, discussions about whether something is "required" or "difficult" or "impossible" are largely beside the point, and also raise serious concerns.  If a particular use of RDS data is excluded because it's not absolutely required in every instance, or because it's "difficult" but not "impossible" to work without it, there are significant costs and consequences that would arise from any such exclusion.  Something that is more difficult is more costly, more complex, more time-consuming, more prone to failure, more burdensome and/or more resource-intensive.  Difficulty is a deterrent. 
> I hope to hear the same arguments in this and future PDPs when contracted parties voice concerns regarding the costs of implementation of new policies.
> And I hope you are not suggesting that just because it may be more difficult or costly to access certain data (data that would be considered legally protected private data in many jurisdictions) we cannot erect such barriers as may be necessary to protect the rights of those affected. 
> I repeat an argument I raised a few weeks back: In most jurisdictions you would need to first obtain a court order to access the data of a internet subscriber or hosting service customer. As the data is the same and these services are usually closer to the violation than those of the domain registrant, why should we consider that the private data of that registrant be protected any less? The same rules should apply to these services.
> 
>> We have no mandate as a group to make things more difficult for current users of RDS-type data or to deter legitimate activity.
> We have a mandate, not to make it more difficult, but to determine how anyone can access this data. As there are access levels contemplated in the EWG report, I frankly do not understand why you even make an issue of that. If access levels and restrictions are part of the basic design, there already is one barrier that currently does not exist, hence the difficulty to access is already increased of todays' standards.
> 
> Best,
> 
> VG
>> 
>> Greg Shatan
>> 
>> 
>> 
>> 
>> 
>> On Thu, Sep 22, 2016 at 9:54 AM, Rob Golding <rob.golding at astutium.com> wrote:
>> Safeguard 3: Should Registry Operators undertake periodic security
>> checks to analyze whether domains in its gTLD are being used for
>> threats to security, such as pharming, phishing, malware and botnets?
>> 
>> None of which requires "registration" data ...
>> 
>> pharming = content
>> phishing = content
>> malware = content
>> botnets = traffic [and are primarily ip based not domain based]
>> etc
>> 
>> 
>> Rob
>> 
>> _______________________________________________
>> 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
> 
> -- 
> Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung.
> 
> Mit freundlichen Grüßen,
> 
> Volker A. Greimann
> - Rechtsabteilung -
> 
> Key-Systems GmbH
> Im Oberen Werk 1
> 66386 St. Ingbert
> Tel.: +49 (0) 6894 - 9396 901
> Fax.: +49 (0) 6894 - 9396 851
> Email: vgreimann at key-systems.net
> 
> Web: www.key-systems.net / www.RRPproxy.net
> www.domaindiscount24.com / www.BrandShelter.com
> 
> Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook:
> www.facebook.com/KeySystems
> www.twitter.com/key_systems
> 
> Geschäftsführer: Alexander Siffrin
> Handelsregister Nr.: HR B 18835 - Saarbruecken 
> Umsatzsteuer ID.: DE211006534
> 
> Member of the KEYDRIVE GROUP
> www.keydrive.lu 
> 
> Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen.
> 
> --------------------------------------------
> 
> Should you have any further questions, please do not hesitate to contact us.
> 
> Best regards,
> 
> Volker A. Greimann
> - legal department -
> 
> Key-Systems GmbH
> Im Oberen Werk 1
> 66386 St. Ingbert
> Tel.: +49 (0) 6894 - 9396 901
> Fax.: +49 (0) 6894 - 9396 851
> Email: vgreimann at key-systems.net
> 
> Web: www.key-systems.net / www.RRPproxy.net
> www.domaindiscount24.com / www.BrandShelter.com
> 
> Follow us on Twitter or join our fan community on Facebook and stay updated:
> www.facebook.com/KeySystems
> www.twitter.com/key_systems
> 
> CEO: Alexander Siffrin
> Registration No.: HR B 18835 - Saarbruecken 
> V.A.T. ID.: DE211006534
> 
> Member of the KEYDRIVE GROUP
> www.keydrive.lu 
> 
> This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone.
> 
> 
> 
> _______________________________________________
> 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/20160923/be7b55ff/attachment.html>