Versions Compared

Old Version 9

changes.mady.by.user Lisa Phifer

Saved on

compared with

New Version Current

changes.mady.by.user Lisa Phifer

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

2) Continue deliberation on the charter question/subquestion 5.1:

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

a   a) Review of poll results: AnnotatedResultsV2-Poll-on-Purpose-from-2MayCall.pdf

b   b) 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."

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

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

...

4) Update on definition(s) to replaced by replace "authoritative"

5) Confirm action items and proposed decision points

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

 


Joining late: Alex Deacon
Apologies: Holly Raiche, Sara Bockey, Susan Prosser, Benny Samuelsen, Paul Keating
Transcription Transcript


Notes RDS PDP WG Meeting 

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.

  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:
TO BE LISTED HERE
  • 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-from-2MayCall.pdf

  • 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
  • 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
  • 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
poll results: SummaryResults-Poll-on-Purpose-from-2MayCall.pdf
  • the relevant section in the GNSO WG Guidelines for those that want more information? (section 3.6 - Standard Methodology for Making Decisions).
  • 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
  • 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]
  • 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
  • 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

  • Result of poll question 3: 95% (all but two respondents) want to further deliberate on possible requirement(s) for allowing access to "thin data"...
  • Options are not mutually exclusive; respondents were asked to check all that apply
  • Options “a” and “c” are conceptually different – deliberate “c” and “d” separate from “a” and “b”
  • 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
  • Options “a” and "b" are meant to indicate that some identification could be required for access to "thin data", but not necessarily validated
  • WG members should review the comments, and are encouraged to bring them up during deliberation where relevant
  • 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)

  • 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
  • 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
  • Possible rewording of the question: Should access to "thin data" be allowed without any identification?
  • From the AC Chat: Friendly amendment, then: "_Requestor identification_ for access to thin data elements should be…" and so on
  • Questions on rate limiting may raise concerns on bulk access to data
  • 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
  • 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?
  • 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
  • There should be a balanced approach in policy on rate limiting to ensure reasonable access to data
  • Are questions 1 and 2 irrelevant, considering the tentative Working Group agreement on poll question 2?
  • 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.
  • 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
  • Regarding question 2, inability to validate requiestor identification makes in undesirable becaue it may lead to inaccurate (fictitious) IDs being supplied by requestors
  • Should the RDS be designed to allow automated access - CAPTCHA would not apply to non-web access
  • 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)
  • 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
  • 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
  • Care must be taken to avoid operational difficulties that could result if policies restrict use of rate limiting
  • 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)
  • Depending on who you are, you may get a different answer (maybe bypass rate limiting, maybe access to more data, etc) - authentication determines that
  • For question 2, if requestor authentication is not desired, option b) may need to be reworded
  • Anonymous access to “thin data” may not require authenticated query, while access to gated data that requires some form of authenticated identification could
  • Not having a definition of "total anonymity" makes it difficult to agree on the previous point
  • From AC Chat: Possible requirement: "Thin data" elements must be accessible with or without authentication.
  • "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)
  • "Thin data" elements must be accessible with or without authentication" can be interpreted TWO different ways - could this be misinterpreted as requiring authentication?
  • How about Thin data elements are to be accessible regardless of the level of authentication of the requestor?
  • Can the question be reworded to read: "thin data" must be accessible without authentication
  • 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
  • Continue discussion on this during next week's call
  • 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
  • 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 ITEMS TO BE LISTED HERE 

    • WG Agreement: gTLD registration "thin data" should be accessible without requiring inquirers to identify themselves or state their purpose

    • 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

    • 9 May Call Poll -
      • Link to participate: POLL CLOSED @ COB 13 May 2017
      • PDF of Poll Questions: Poll-from-9MayCall.pdf
      • Poll Results: to be discussed at 17 May RDS PDP meeting