[gnso-rds-pdp-wg] IMPROTANT - Action Items and Notes from Next-Generation RDS PDP Working Group Call - 17 May 2017
Paul Keating
Paul at law.es
Wed May 17 16:13:55 UTC 2017
What is the problem with harvesting?
This is public data. There is no Intellectual Property right in the data
itself.
Asking for ME.
Paul
From: <gnso-rds-pdp-wg-bounces at icann.org> on behalf of Greg Shatan
<gregshatanipc at gmail.com>
Date: Wednesday, May 17, 2017 at 6:02 PM
To: Volker Greimann <vgreimann at key-systems.net>
Cc: RDS PDP WG <gnso-rds-pdp-wg at icann.org>
Subject: Re: [gnso-rds-pdp-wg] IMPROTANT - Action Items and Notes from
Next-Generation RDS PDP Working Group Call - 17 May 2017
> Why do we want to prevent harvesting? Asking for a friend.
>
> Greg Shatan
> C: 917-816-6428
> S: gsshatan
> gregshatanipc at gmail.com <mailto:gregshatanipc at gmail.com>
>
>
> On Wed, May 17, 2017 at 11:58 AM, Volker Greimann <vgreimann at key-systems.net>
> wrote:
>>
>>
>>
>> I can see dozens of legitimate reasons for restricting access that are not
>> related to the efficiencies of the data retrieval system, first of which is
>> harvesting prevention.
>>
>>
>>
>> Volker
>>
>>
>>
>>
>> Am 17.05.2017 um 17:55 schrieb Paul Keating:
>>
>>
>>>
>>> ³There must be no RDS policies that prevent RDS operators from applying
>>> operational controls such as rate limiting and CAPTCHA, provided that they
>>> do not unreasonably restrict legitimate access.³,
>>>
>>>
>>>
>>>
>>> Caveat. The rate controls must be related to controlling the
>>> efficiiciencies of the underlying data retrieval system and not for o there
>>> purposes.
>>>
>>>
>>>
>>>
>>> PRK
>>>
>>> From: <gnso-rds-pdp-wg-bounces at icann.org> on behalf of Amr Elsadr
>>> <amr.elsadr at icann.org>
>>> Date: Wednesday, May 17, 2017 at 9:48 AM
>>> To: "gnso-rds-pdp-wg at icann.org" <gnso-rds-pdp-wg at icann.org>
>>> Subject: [gnso-rds-pdp-wg] IMPROTANT - Action Items and Notes from
>>> Next-Generation RDS PDP Working Group Call - 17 May 2017
>>>
>>>
>>>
>>>
>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Dear Working Group Members,
>>>>
>>>>
>>>>
>>>> Please find below the action items and notes from today¹s Working Group
>>>> call.
>>>>
>>>>
>>>>
>>>> Thanks.
>>>>
>>>>
>>>>
>>>> Amr
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> These high-level notes are designed to help PDP WG members navigate through
>>>> the content of the call and are not meant as a substitute for the
>>>> transcript and/or recording. The MP3, transcript, and chat are provided
>>>> separately and are posted on the wiki here:
>>>> https://community.icann.org/x/HMPRAw <https://community.icann.org/x/HMPRAw>
>>>>
>>>>
>>>>
>>>> Action Items:
>>>>
>>>>
>>>>
>>>> 1. Newcomers to RSVP to Newcomer Tutorial invitation if you plan to attend
>>>>
>>>> 2. Staff to launch poll the test revised item 2) in statement of purpose
>>>> <https://community.icann.org/download/attachments/56986791/KeyConceptsDelib
>>>> eration-WorkingDraft-9May2017.pdf?version=1&modificationDate=1494372838376&
>>>> api=v2> and revised 2 May agreement:
>>>>
>>>> a. The test revised item 2) in statement of purpose
>>>> <https://community.icann.org/download/attachments/56986791/KeyConceptsDelib
>>>> eration-WorkingDraft-9May2017.pdf?version=1&modificationDate=1494372838376&
>>>> api=v2> : "2) 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.²
>>>>
>>>> b. Revised 2 May agreement: "gTLD registration "thin data" must be
>>>> accessible without requestor identification, authentication, or stated
>>>> purpose"
>>>>
>>>> WG members to participate in poll by COB Saturday 20 May.
>>>>
>>>> 3. Rod Rasmussen and Vaibhav Aggarwal to work together to define what
>>>> "unreasonably restrict legitimate access" means in the context of this
>>>> statement ³There must be no RDS policies that prevent RDS operators from
>>>> applying operational controls such as rate limiting and CAPTCHA, provided
>>>> that they do not unreasonably restrict legitimate access.³, and propose
>>>> that definition to WG mailing list, preferably before next week's WG call
>>>>
>>>>
>>>>
>>>> Notes:
>>>>
>>>>
>>>>
>>>> 1) Roll Call/SOI Updates
>>>>
>>>> * Attendance will be taken from AC
>>>> * Please remember to state your name before speaking and remember to mute
>>>> your microphones when not speaking
>>>> * SOI updates: none
>>>>
>>>> 2) Brief updates
>>>> a) Newcomer tutorial plans:
>>>>
>>>> * Tuesday 23 May, immediately following WG Call
>>>> * Recording to be available for on-demand replay
>>>>
>>>> Action Item: Newcomers to RSVP to Newcomer Tutorial invitation if you plan
>>>> to attend
>>>>
>>>> b) ICANN59 meeting plans:
>>>>
>>>> * Monday 26 June Cross-Community Session on RDS
>>>> * Tuesday 27 June Face-to-Face RDS PDP WG Session
>>>>
>>>> 3) Review proposed-final definition(s) to replace "authoritative" in
>>>> Statement of Purpose, Item 2):
>>>>
>>>> *
>>>> https://community.icann.org/download/attachments/64078620/DataOfRecord-Prop
>>>> osal.pdf
>>>> * Recommendation on how to proceed with replacement term for
>>>> "authoritative"
>>>> * Starting with poll results from 28 March for Statement of Purpose item 2)
>>>> - substitute term "Data of Record" so that item will read:
>>>> * "2) 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.²
>>>> * Definition: "the data set at a given time relevant to a given
>>>> registration object that expresses the data provided in the then-current
>>>> registration for that object.²
>>>> * Can still later consider "source of record" but does not appear needed to
>>>> convey intent of this item in the statement of purpose
>>>>
>>>> Proposed WG Agreement (to test with poll): "2) 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.² (including footnoted definition above)
>>>>
>>>> 4) Continue deliberation on the charter question 5: What steps should be
>>>> taken to control "thin data" access?
>>>>
>>>> * See handout
>>>> https://community.icann.org/download/attachments/64078620/Charter%20Questio
>>>> n%205%20-%20Handout%20-%20For17MayCall%20v2.pdf
>>>> * Full results available at
>>>> https://community.icann.org/download/attachments/64078620/SummaryResults-Po
>>>> ll-from-9MayCall.pdf
>>>>
>>>> a) Is "thin data" access authentication required or allowed?
>>>>
>>>> * Proposed answer: Based on Poll Question 2) Option e)
>>>> * "Thin data elements must be accessible without requestor authentication."
>>>> * With 33 responses, option e) had greatest support and least opposition -
>>>> but not rough consensus
>>>> * Does "inquirers identifying themselves" or "authentication" imply a
>>>> person rather than a machine making the request?
>>>> * First proposed change "gTLD registration "thin data" should be accessible
>>>> without inquirer identification or stating purpose".
>>>> * Consider combining option e) with this agreement, and using "requestor"
>>>> instead of "inquirer" for consistency
>>>> * Revised/combined proposed change "gTLD registration "thin data" must be
>>>> accessible without requestor identification, authentication, or stated
>>>> purpose".
>>>>
>>>> Proposed WG Agreement (to test with poll): "gTLD registration "thin data"
>>>> must be accessible without requestor identification, authentication, or
>>>> stated purpose".
>>>>
>>>> b) Is "thin data" access anonymity required or allowed?
>>>>
>>>> * Proposed answer: Based on Poll Question 2) Comment 9:
>>>> * "Access to thin registration data must be provided to anonymous
>>>> requestors."
>>>> * Does anyone think we must refer to anonymity or is proposed agreement in
>>>> a) sufficient?
>>>> * Introduces a new term that may be problematic.
>>>> * Why do we need to define anonymous now? Thick data for LEA we may need to
>>>> define anonymous and untraceable and a whole slew of things but we are only
>>>> on thin data now, right?
>>>> * The current proposal (under a above) says what the requestor does _not_
>>>> have to give, rather than trying to create an attribute of the requestor
>>>>
>>>> c) Do we need to define "authentication"?
>>>>
>>>> * We might need to define it later (since we say that there is no
>>>> authentification required for thin data) - may need to define it for thick
>>>> data
>>>> * Is "according to policy" implicit in WG agreements? We haven't yet agreed
>>>> on specific "thin data" elements yet
>>>>
>>>> Action Item: Staff to launch poll the test revised item 2) in statement of
>>>> purpose and revised 2 May agreement (the two Proposed WG Agreements above).
>>>> WG members to participate in poll by COB Saturday 20 May.
>>>>
>>>> d) Should policies allow or prevent application of operational controls?
>>>>
>>>> * Rough consensus WG Agreement (75%) on Poll Question 3):
>>>> * "There must be no RDS policies that prevent RDS operators from applying
>>>> operational controls such as rate limiting and CAPTCHA, provided that they
>>>> do not unreasonably restrict legitimate access."
>>>> * Need to define specific policy for "reasonable" and "legitimate" during
>>>> Phase 2 of this PDP?
>>>> * Is there a need for an explicit statement like this? If the information
>>>> is public, is it necessary to limit to prevent scraping? Or is rate
>>>> limiting being used to limit legitimate access - can't ignore this
>>>> gaming/artificial limit possibility.
>>>> * Note 2013 RAA 3.3.5 states "Registrar shall permit use of data it
>>>> provides in response to queries for any lawful purposes except to...(b)
>>>> enable high volume, automated, electronic processes that send queries or
>>>> data to the systems of any Registry Operator or ICANN-Accredited registrar,
>>>> except as reasonably necessary to register domain names or modify existing
>>>> registrations."
>>>> * Perhaps rather than saying something about rate-limiting per se, we need
>>>> an SLA about the level of access that must be supported.
>>>> * Remaining silent on this point may lead to policies that interfere with
>>>> use of operational controls - but using "unreasonably restrict legitimate
>>>> access" may leap this too open ended
>>>> * Agreed to put this rough consensus point on hold, pending definition of
>>>> what "unreasonably restrict legitimate access" means
>>>>
>>>> Action Item: Rod Rasmussen and Vaibhav Aggarwal to work together to define
>>>> what "unreasonably restrict legitimate access" means in the context of this
>>>> statement and propose that definition to WG mailing list, preferrably
>>>> before next week's WG call.
>>>>
>>>> e) Review all of charter question 5 sub-questions with goal to complete
>>>> first pass deliberation on "thin data" access in May
>>>>
>>>> * DEFERRED TO 23 MAY WG MEETING
>>>>
>>>> 5) Confirm action items and proposed decision points
>>>>
>>>> * Proposed WG Agreement (to test with poll): "2) 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.² (including footnoted definition above)
>>>> * Proposed WG Agreement (to test with poll): "gTLD registration "thin data"
>>>> must be accessible without requestor identification, authentication, or
>>>> stated purpose".
>>>> * Action Item: Newcomers to RSVP to Newcomer Tutorial invitation if you
>>>> plan to attend
>>>> * Action Item: Staff to launch poll the test revised item 2) in statement
>>>> of purpose and revised 2 May agreement (the two Proposed WG Agreements
>>>> above). WG members to participate in poll by COB Saturday 20 May.
>>>> * Action Item: Rod Rasmussen and Vaibhav Aggarwal to work together to
>>>> define what "unreasonably restrict legitimate access" means in the context
>>>> of this statement and propose that definition to WG mailing list,
>>>> preferably before next week's WG call.
>>>>
>>>> 6) Confirm next meeting date: 23 May 2017 at 16:00 UTC
>>>>
>>>>
>>>>
>>>> Meeting Materials
>>>>
>>>> * Data of Record Proposal
>>>> <https://community.icann.org/download/attachments/64078620/DataOfRecord-Pro
>>>> posal.pdf?version=1&modificationDate=1494989338000&api=v2>
>>>> * Charter Question 5 - Handout - For17MayCall.pdf
>>>> <https://community.icann.org/download/attachments/64078620/Charter%20Questi
>>>> on%205%20-%20Handout%20-%20For17MayCall%20v2.pdf?version=1&modificationDate
>>>> =1494961615000&api=v2>
>>>> * KeyConceptsDeliberation-WorkingDraft-9May2017.pdf
>>>> <https://community.icann.org/download/attachments/56986791/KeyConceptsDelib
>>>> eration-WorkingDraft-9May2017.pdf?version=1&modificationDate=1494372838376&
>>>> api=v2> and doc
>>>> <https://community.icann.org/download/attachments/56986791/KeyConceptsDelib
>>>> eration-WorkingDraft-9May2017.docx?version=1&modificationDate=1494372853897
>>>> &api=v2>
>>>>
>>>> * 9 May Call Poll Results -
>>>>> * PDF of Poll Questions: Poll-from-9MayCall.pdf
>>>>> <https://community.icann.org/download/attachments/64078610/Poll-from-9MayC
>>>>> all.pdf?version=1&modificationDate=1494374689000&api=v2>
>>>>> * SurveyMonkey Summary Poll Results: SummaryResults-Poll-from-9MayCall.pdf
>>>>> <https://community.icann.org/download/attachments/64078620/SummaryResults-
>>>>> Poll-from-9MayCall.pdf?version=1&modificationDate=1494787660000&api=v2>
>>>>> * SurveyMonkey Raw Data Poll Results:
>>>>> RawDataResults-Poll-from-9MayCall.zip
>>>>> <https://community.icann.org/download/attachments/64078620/RawDataResults-
>>>>> Poll-from-9MayCall.zip?version=1&modificationDate=1494787676000&api=v2>
>>>>> and XLS
>>>>> <https://community.icann.org/download/attachments/64078620/RawDataResults-
>>>>> Poll-from-9MayCall.xls?version=1&modificationDate=1494787693000&api=v2>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________ 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.orghttps://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 <tel:+49%206894%209396901>
>> Fax.: +49 (0) 6894 - 9396 851 <tel:+49%206894%209396851>
>> Email: vgreimann at key-systems.net
>>
>> Web: www.key-systems.net <http://www.key-systems.net> / www.RRPproxy.net
>> <http://www.RRPproxy.net> www.domaindiscount24.com
>> <http://www.domaindiscount24.com> / www.BrandShelter.com
>> <http://www.BrandShelter.com>
>>
>> Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook:
>> www.facebook.com/KeySystems <http://www.facebook.com/KeySystems>
>> www.twitter.com/key_systems <http://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 <http://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 <tel:+49%206894%209396901>
>> Fax.: +49 (0) 6894 - 9396 851 <tel:+49%206894%209396851>
>> Email: vgreimann at key-systems.net
>>
>> Web: www.key-systems.net <http://www.key-systems.net> / www.RRPproxy.net
>> <http://www.RRPproxy.net> www.domaindiscount24.com
>> <http://www.domaindiscount24.com> / www.BrandShelter.com
>> <http://www.BrandShelter.com>
>>
>> Follow us on Twitter or join our fan community on Facebook and stay updated:
>> www.facebook.com/KeySystems <http://www.facebook.com/KeySystems>
>> www.twitter.com/key_systems <http://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 <http://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
>
> _______________________________________________ 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/20170517/7a246d24/attachment-0001.html>
More information about the gnso-rds-pdp-wg
mailing list