Versions Compared

Old Version 28

changes.mady.by.user Terri Agnew

Saved on

compared with

New Version 29

changes.mady.by.user Lisa Phifer

Saved on

Key

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

...


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: 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-Proposal.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?

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, preferrably before next week's WG call.

6) Confirm next meeting date: 23 May 2017 at 16:00 UTC

 

Meeting Materials

17 May Call Poll -