[gnso-rds-pdp-wg] IMPROTANT - Action Items and Notes from Next-Generation RDS PDP Working Group Call - 17 May 2017

Wed May 17 16:14:42 UTC 2017

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/KeyConceptsDelibe
>>> ration-WorkingDraft-9May2017.pdf?version=1&modificationDate=1494372838376&ap
>>> i=v2>  and revised 2 May agreement:
>>>  
>>> a. The test revised item 2) in statement of purpose
>>> <https://community.icann.org/download/attachments/56986791/KeyConceptsDelibe
>>> ration-WorkingDraft-9May2017.pdf?version=1&modificationDate=1494372838376&ap
>>> i=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-Propo
>>> sal.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%20Question
>>> %205%20-%20Handout%20-%20For17MayCall%20v2.pdf
>>> * Full results available at
>>> https://community.icann.org/download/attachments/64078620/SummaryResults-Pol
>>> l-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-Prop
>>> osal.pdf?version=1&modificationDate=1494989338000&api=v2>
>>> * Charter Question 5 - Handout - For17MayCall.pdf
>>> <https://community.icann.org/download/attachments/64078620/Charter%20Questio
>>> n%205%20-%20Handout%20-%20For17MayCall%20v2.pdf?version=1&modificationDate=1
>>> 494961615000&api=v2>
>>> * KeyConceptsDeliberation-WorkingDraft-9May2017.pdf
>>> <https://community.icann.org/download/attachments/56986791/KeyConceptsDelibe
>>> ration-WorkingDraft-9May2017.pdf?version=1&modificationDate=1494372838376&ap
>>> i=v2>  and doc 
>>> <https://community.icann.org/download/attachments/56986791/KeyConceptsDelibe
>>> ration-WorkingDraft-9May2017.docx?version=1&modificationDate=1494372853897&a
>>> pi=v2> 
>>>  
>>> * 9 May Call Poll Results -
>>>> * PDF of Poll Questions: Poll-from-9MayCall.pdf
>>>> <https://community.icann.org/download/attachments/64078610/Poll-from-9MayCa
>>>> ll.pdf?version=1&modificationDate=1494374689000&api=v2>
>>>> * SurveyMonkey Summary Poll Results: SummaryResults-Poll-from-9MayCall.pdf
>>>> <https://community.icann.org/download/attachments/64078620/SummaryResults-P
>>>> oll-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-P
>>>> oll-from-9MayCall.zip?version=1&modificationDate=1494787676000&api=v2>  and
>>>> XLS 
>>>> <https://community.icann.org/download/attachments/64078620/RawDataResults-P
>>>> oll-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-w>>
g
>>  
>  
>  
> -- 
> 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 <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
> Fax.: +49 (0) 6894 - 9396 851
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20170517/dccfd932/attachment-0001.html>