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

Wed May 17 15:55:40 UTC 2017

³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
>  
> 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/KeyConceptsDelibera
> tion-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/KeyConceptsDelibera
> tion-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-Proposa
> l.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%2
> 05%20-%20Handout%20-%20For17MayCall%20v2.pdf
> * Full results available at
> https://community.icann.org/download/attachments/64078620/SummaryResults-Poll-
> 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-Propos
> al.pdf?version=1&modificationDate=1494989338000&api=v2>
> * Charter Question 5 - Handout - For17MayCall.pdf
> <https://community.icann.org/download/attachments/64078620/Charter%20Question%
> 205%20-%20Handout%20-%20For17MayCall%20v2.pdf?version=1&modificationDate=14949
> 61615000&api=v2> 
> * KeyConceptsDeliberation-WorkingDraft-9May2017.pdf
> <https://community.icann.org/download/attachments/56986791/KeyConceptsDelibera
> tion-WorkingDraft-9May2017.pdf?version=1&modificationDate=1494372838376&api=v2
> >  and doc 
> <https://community.icann.org/download/attachments/56986791/KeyConceptsDelibera
> tion-WorkingDraft-9May2017.docx?version=1&modificationDate=1494372853897&api=v
> 2> 
> * 9 May Call Poll Results -
>> * PDF of Poll Questions: Poll-from-9MayCall.pdf
>> <https://community.icann.org/download/attachments/64078610/Poll-from-9MayCall
>> .pdf?version=1&modificationDate=1494374689000&api=v2>
>> * SurveyMonkey Summary Poll Results: SummaryResults-Poll-from-9MayCall.pdf
>> <https://community.icann.org/download/attachments/64078620/SummaryResults-Pol
>> l-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-Pol
>> l-from-9MayCall.zip?version=1&modificationDate=1494787676000&api=v2>  and XLS
>> <https://community.icann.org/download/attachments/64078620/RawDataResults-Pol
>> l-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

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