[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:41:14 UTC 2017 

But you have not yet explained why any of the un-named examples are
problematic for THIN data.

From:  John Horton <john.horton at legitscript.com>
Date:  Wednesday, May 17, 2017 at 6:33 PM
To:  Paul Keating <paul at law.es>
Cc:  Volker Greimann <vgreimann at key-systems.net>, 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

> +1
> 
> 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>   |
> Google+ <https://plus.google.com/112436813474708014933/posts>
> 
> 
> 
> 
> 
> On Wed, May 17, 2017 at 12:14 PM, Paul Keating <Paul at law.es> wrote:
>> I see none.  This is THIN data.
>> 
>> From:  <gnso-rds-pdp-wg-bounces at icann.org> on behalf of Volker Greimann
>> <vgreimann at key-systems.net>
>> Date:  Wednesday, May 17, 2017 at 5:58 PM
>> To:  <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
>> 
>>>     
>>>  
>>> 
>>> 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/KeyConceptsDeli
>>>>> beration-WorkingDraft-9May2017.pdf?version=1&modificationDate=149437283837
>>>>> 6&api=v2>  and revised 2 May agreement:
>>>>>  
>>>>> a. The test revised item 2) in statement of purpose
>>>>> <https://community.icann.org/download/attachments/56986791/KeyConceptsDeli
>>>>> beration-WorkingDraft-9May2017.pdf?version=1&modificationDate=149437283837
>>>>> 6&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-Pro
>>>>> posal.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%20Questi
>>>>> on%205%20-%20Handout%20-%20For17MayCall%20v2.pdf
>>>>> * Full results available at
>>>>> https://community.icann.org/download/attachments/64078620/SummaryResults-P
>>>>> oll-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-Pr
>>>>> oposal.pdf?version=1&modificationDate=1494989338000&api=v2>
>>>>> * Charter Question 5 - Handout - For17MayCall.pdf
>>>>> <https://community.icann.org/download/attachments/64078620/Charter%20Quest
>>>>> ion%205%20-%20Handout%20-%20For17MayCall%20v2.pdf?version=1&modificationDa
>>>>> te=1494961615000&api=v2>
>>>>> * KeyConceptsDeliberation-WorkingDraft-9May2017.pdf
>>>>> <https://community.icann.org/download/attachments/56986791/KeyConceptsDeli
>>>>> beration-WorkingDraft-9May2017.pdf?version=1&modificationDate=149437283837
>>>>> 6&api=v2>  and doc
>>>>> <https://community.icann.org/download/attachments/56986791/KeyConceptsDeli
>>>>> beration-WorkingDraft-9May2017.docx?version=1&modificationDate=14943728538
>>>>> 97&api=v2> 
>>>>>  
>>>>> * 9 May Call Poll Results -
>>>>>> * PDF of Poll Questions: Poll-from-9MayCall.pdf
>>>>>> <https://community.icann.org/download/attachments/64078610/Poll-from-9May
>>>>>> Call.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.orghttps://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/e45889b5/attachment-0001.html>

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