[gnso-rds-pdp-wg] IMPORTANT: Action Items and Notes from the Next-Generation RDS PDP Working Group Call - 9 May 2017

Amr Elsadr amr.elsadr at icann.org
Tue May 9 21:57:56 UTC 2017


Dear Working Group Members,

Please find the action items, notes and links to meeting materials and document from today’s Working Group call below.

Thanks.

Amr


Action Items:


1.       Leadership team to review call notes and develop the questions and the answer options for this week’s poll, to be posted by Staff by COB 9 May

2.       Working Group members to participate in this week's poll before the deadline on Saturday, 13 May COB

3.       Staff to incorporate last week's Working Group agreement in the working draft; updated draft to be posted at https://community.icann.org/x/EsPRAw

4.       Any Working Group members are interested in a one-hour RDS PDP WG newcomers tutorial on background and context, please respond to the survey: https://www.surveymonkey.com/r/3GG6CRR before the deadline on Friday, 12 May COB

Notes RDS PDP WG Meeting – 9 May 2017:
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/EsPRAw

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.       Continue deliberation on the charter question/subquestion 5.1:

"Should gTLD registration "thin data" be entirely public or should access be controlled?

·         Review of poll results:

https://community.icann.org/download/attachments/64078610/AnnotatedResultsV2-Poll-on-Purpose-from-2MayCall.pdf

o    Results of poll question 2: 84% agreed with the statement: gTLD registration "thin data" should be accessible without requiring inquirers to identify themselves or state their purpose

o    84% enough to assume rough consensus at this stage - note that this does not indicate a final WG decision; formal consensus will be determined at the end of Phase 1

o    As per the Charter and the GNSO Working Group Guidelines, the standard methodology for making decisions in a PDP WG is by assessing the level of consensus. This is not done through voting but through an iterative process of assessment conducted by the WG Chair(s). See the relevant section in the GNSO WG Guidelines<https://gnso.icann.org/en/council/annex-1-gnso-wg-guidelines-01sep16-en.pdf> for those that want more information? (section 3.6 - Standard Methodology for Making Decisions).

o    Rough consensus on Question 2 will be recorded in the WG's key concepts deliberation working document and used by the WG to progress deliberation on other points

o    From the AC Chat: The most recent version of our working document is always posted at the top of this wiki page: https://community.icann.org/display/gTLDRDS/Phase+1+Documents[community.icann.org<https://community.icann.org/display/gTLDRDS/Phase+1+Documents%5bcommunity.icann.org>]

o    Assumption is that there is rough consensus on what "thin data" elements are required - this needs to be detailed in the future - data element requirements will be identified individually when we continue deliberating on the Data Elements charter question

o    Would registrants want all "thin data" be displayed? Would registrants want a say in what "thin data" elements associated with their domain name registrations is displayed?
WG Agreement: gTLD registration "thin data" should be accessible without requiring inquirers to identify themselves or state their purpose

o    Result of poll question 3: 95% (all but two respondents) want to further deliberate on possible requirement(s) for allowing access to "thin data"...

o    Options are not mutually exclusive; respondents were asked to check all that apply

o    Options “a” and “c” are conceptually different – deliberate “c” and “d” separate from “a” and “b”

o    From AC Chat: What we conclude from Q3 is that there is interest in deliberating these - this poll question did not seek agreement or disagreement to each possible requirement

o    Options “a” and "b" are meant to indicate that some identification could be required for access to "thin data", but not necessarily validated

o    WG members should review the comments, and are encouraged to bring them up during deliberation where relevant

o    Slide 3 in Charter Question 5 - Handout is a starting point for deliberation

·         Record rough consensus on WG agreement in Section 5.1 of working document:

"gTLD registration "thin data" should be accessible without requiring inquirers to identify themselves or state their purpose."

·         Deliberate on other possible requirement(s) for allowing access to "thin data"

(e.g., possible requirements for identification, authentication, and anti-abuse measures)

o    Suggestion to separate questions 1 and 2 from 3 and 4 - Qs 3 and 4 more concerned with operational issues, 1 and 2 are more focused on policy issues

o    In WHOIS today, one does not query "thin data" elements, one submits a query for a domain name - "thin data" elements are included in what the inquirer gets back

o    Possible rewording of the question: Should access to "thin data" be allowed without any identification?

o    From the AC Chat: Friendly amendment, then: "_Requestor identification_ for access to thin data elements should be…" and so on

o    Questions on rate limiting may raise concerns on bulk access to data

o    Might be necessary to create a policy for an independent solution regarding bulk access to data, which does not interfere with or create operational issues/difficulties

o    Rate limiting might be an implementation measure for a policy that prevents bulk access to data, so it is a policy issue from that perspective?

o    Regarding 1 and 2: Care should be taken to ensure that the design of the next-gen RDS is not compromised by policy decisions with unintended negative consequences

o    There should be a balanced approach in policy on rate limiting to ensure reasonable access to data

o    Are questions 1 and 2 irrelevant, considering the tentative Working Group agreement on poll question 2?

o    From the AC Chat: My point on different "interfaces" can also be thought of as needing to make different types of queries depending upon the type of request you're making.  I would argue that you should get "thin" data for "free" when you're making a gated data element(s) query.  If you "disallow" requestor identification for thin data, then you have to make two different queries to get the data you need - one with your ID and one without.

o    As noted in question 4, CAPTCHA is a web-based access control measure – web-based queries are a minority of WHOIS queries - very specific barrier to determine that inquirer is a human

o    Regarding question 2, inability to validate requiestor identification makes in undesirable becaue it may lead to inaccurate (fictitious) IDs being supplied by requestors

o    Should the RDS be designed to allow automated access - CAPTCHA would not apply to non-web access

o    Part of the problem with accuracy of data is people not wanting their PII to be freely accessible – Working Group should not recreate this problem by requiring the identity of inquirers (requestors submitting queries)

o    Rate limiting should be unpacked: by individual, by IP address, by enquiring system, etc... - policy implications should not be ignored - not just an operational issue

o    One query should grant access to all data that is permissibly accessible (thin and thick, when applicable) - access to different sets of data on a single domain name should not require multiple queries

o    Care must be taken to avoid operational difficulties that could result if policies restrict use of rate limiting

o    Unauthenticated requestor MUST have access to thin data elements, within the required operational bounds of the service (so rate limiting for anti-DoS is acceptable)

o    Depending on who you are, you may get a different answer (maybe bypass rate limiting, maybe access to more data, etc) - authentication determines that

o    For question 2, if requestor authentication is not desired, option b) may need to be reworded

o    Anonymous access to “thin data” may not require authenticated query, while access to gated data that requires some form of authenticated identification could

o    Not having a definition of "total anonymity" makes it difficult to agree on the previous point

o    From AC Chat: Possible requirement: "Thin data" elements must be accessible with or without authentication.

o    "Allowed but not required" may create a situation where access differs from one provider to another (e.g., one provider requires authentication while another does not, for access to the same data)

o    "Thin data" elements must be accessible with or without authentication" can be interpreted TWO different ways - could this be misinterpreted as requiring authentication?

o    How about Thin data elements are to be accessible regardless of the level of authentication of the requestor?

o    Can the question be reworded to read: "thin data" must be accessible without authentication

o    Reason to include with or without is meant to not preclude authentication as a requirement as per last week's agreement - may need to be more specific in rewording the poll answer options

o    Continue discussion on this during next week's call

o    ACTION ITEM: Leadership team to review call notes and develop questions and answer options for this week’s poll, to be posted by Staff by COB 9 May 2017

o    ACTION ITEM: Working Group members to participate in this week’s poll before the deadline on Saturday, 13 May COB



3.       Finalize ccTLD questions and plan for distribution

·         All edits and comments have been taken into consideration - questions should be sent to targeted ccTLDs before the end of this week



4.       Update on definition(s) to replace "authoritative"

·         Small team requested to come up with a specific recommendation and rationale to be reviewed during next week's WG call



5.       Confirm action items and proposed decision points

·         ACTION ITEM 1: Leadership team to review call notes and develop questions and answer options for this week’s poll, to be posted by Staff by COB 9 May

·         ACTION ITEM 2: Working Group members to participate in this week's poll before the deadline on Saturday, 13 May COB

·         ACTION ITEM 3: Staff to incorporate last week's Working Group agreement in the working draft; updated draft to be posted at https://community.icann.org/x/EsPRAw

·         ACTION ITEM 4: Any Working Group member interested in a one-hour RDS PDP WG newcomers tutorial on background and context, please respond to the survey: https://www.surveymonkey.com/r/3GG6CRR before the deadline on Friday, 12 May COB



6.       Confirm next meeting date: 17 May 2017 at 05:00 UTC

Meeting Materials

  *   Charter Question 5 - Handout - For9MayCall.pdf<https://community.icann.org/download/attachments/64078610/Charter%20Question%205%20-%20Handout%20-%20For9MayCall.pdf?version=1&modificationDate=1494297483000&api=v2>
  *   NewSection5-Intro-KeyConcepts-21April2017.pdf<https://community.icann.org/download/attachments/64078605/NewSection5-Intro-KeyConcepts-21April2017.pdf?version=1&modificationDate=1492802791000&api=v2> - excerpted from
KeyConceptsDeliberation-WorkingDraft-21April2017.pdf<https://community.icann.org/download/attachments/56986791/KeyConceptsDeliberation-WorkingDraft-21April2017.pdf?version=1&modificationDate=1492966757152&api=v2> and doc<https://community.icann.org/download/attachments/56986791/KeyConceptsDeliberation-WorkingDraft-21April2017.docx?version=1&modificationDate=1492966735704&api=v2>

  *   2 May Call Poll Results -
     *   PDF of Poll Questions: Poll-from-2MayCall.pdf<https://community.icann.org/download/attachments/64078608/Poll-from-2MayCall.pdf?version=1&modificationDate=1493772376000&api=v2>
     *   Annotated Summary for display during call: AnnotatedResultsV2-Poll-on-Purpose-from-2MayCall.pdf<https://community.icann.org/download/attachments/64078610/AnnotatedResultsV2-Poll-on-Purpose-from-2MayCall.pdf>
     *   SurveyMonkey Summary Poll Results: SummaryResults-Poll-on-Purpose-from-2MayCall.pdf<https://community.icann.org/download/attachments/64078610/SummaryResults-Poll-on-Purpose-from-2MayCall.pdf?version=1&modificationDate=1494178391000&api=v2>
     *   SurveyMonkey Raw Data Poll Results: RawResults-Poll-on-Purpose-from-2MayCall.zip<https://community.icann.org/download/attachments/64078610/RawResults-Poll-on-Purpose-from-2MayCall.zip> and XLS<https://community.icann.org/download/attachments/64078610/RawResults-Poll-on-Purpose-from-2MayCall.xls>


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


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