The GNSO Next-Gen RDS PDP Working Group teleconference will take place on Tuesday, 11 October 2016  at 16:00 UTC for 90 minutes  

09:00 PDT, 12:00 EDT, 17:00 London, 18:00 CEST 

For other times: http://tinyurl.com/hua4bm5


Proposed Agenda – RDS PDP WG Meeting - Tuesday, 11 October 2016 at 16:00 UTC for 90 minutes
 
1) Roll call/SOI update
2) Call for volunteers to extract possible requirements from new EU GDPR
3) Continue work on statement of purpose (see latest version, below)
4) Confirm next meeting date: Wednesday 19 October at 05:00 UTC

Attendance

Apologies: Holly Raiche, Michele Neylon, Susan Prosser, Scott Hollenbeck, Greg Shatan, Vaibhav Aggarwal, Volker Greimann, Chris Pelling, Olevie Kouami

Staff:

Mp3

AC Chat

Transcript

 

Notes 11/10 – 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 above. 

1.  Roll call/SOI update

  • Roll call will be taken from AC
  • Please remember to update your SOI

2.  Call for volunteers to extract possible requirements from new EU GDPR

  • Requested volunteers to help Greg Shatan complete extracting possible requirements from GDPR. Greg has good start on this but could use help from WG members to complete this task.
  • Volunteers: Marina Lewis
  • Still welcome additional volunteers

Action #1: Marina Lewis, Greg Shatan, and Lisa Phifer to work together (with any additional volunteers) to complete GDPR task.

 

3.  Continue work on statement of purpose (see latest version, below), starting with section: Specific Purposes for Registration Data and Registration Directory Services

  • On #1, no strong feelings to reword as framing statement rather than purpose
  • Regarding lifecycle, not every TLD has the same lifecycle. SSAC spoke to this in SAC054 by identifying events that may or may not occur in the lifecycle of any specific TLD; however, the lifecycle describes the overall set of events. Note that future new gTLD rounds may include TLDs with different lifecycles as well. Additional text proposed to note that there may be some variations in lifecycle. Every domain has a lifecycle - the RDS tells you about data associated w that domain's lifecycle.
  • On #2, does the statement include too much at this point (e.g., implying there will be controlled rather than unlimited access)? Noted that one possible policy to manage access is to allow unlimited access - that is, an open management policy. Options considered: "manage access to information" vs "provide information about" - proposed resolution is "manage access to and/or provide information about..." - is the purpose providing information, based on some agreed-upon rule set (that is management is not the purpose). See redline for final proposed text encompassing this.
  • On #2, should registries be included? The registry is implicit in the TLD regardless. Removed for now - can always be added
  • On #2, is omission of information about registrants intentional? No, added "registrants" to list.
  • On #3, is this necessary given #2 as providing information - is contact a use case? Can you enable contact with (for example) a registrant without providing information about that registrant? Overlapping but somewhat distinct purpose - RDS may have more than one purpose.
  • On #3, use same phrasing as #2 - "agreed policy"
  • On #3, agree this purpose should include both (1) identifying domain contacts and (2) facilitating contact with those contacts
  • On #3, agreed to not listing types of contacts but allowing them to be defined by "agreed policy"
  • On #3, agreed to replace "facilitate contact with" by "facilitate communication with" domain contacts, based on agreed policy
  • On #4, noted that considerable WG list discussion has occurred regarding "accuracy" - To be discussed but for the moment, focusing on the rest of this purpose... [resolution: move accuracy to separate purpose item, to be discussed]
  • On #4, again, use same phrasing as #2 - "agreed policy"
  • On #4, is this purpose redundant with #2 - "To release data that may not be otherwise publicly available, under specific and explicit conditions, based on agreed policy" - is this different than #2, "To provide information about...based on agreed policy." Is the distinction "may not be otherwise publicly available" necessary or add value to the statement of purpose. Agreed to combine #2 and #4 in next draft, moving [accuracy] to another separate purpose for further discussion.
  • On #2, add "domain contacts" to list of information provided (either in addition to or instead of "registrant")
  • With regard to accuracy, comments included the following:
  • Shouldn't the RDS be an authoritative and accurate source of information? Is this a purpose of the RDS? Should it be a separate and distinct purpose?
  • SAC 055:RecommendationThe SSAC recommends that the Registration Data Policy Committee’s charter should include the requirement to define “accurate registration data” and provide guidance as to how to achieve it.
  • A big part of building trust in an authoritative database is having some comfort that the data is accurate. in light of this, part of the purpose of the RDS should be to have accuracy to build such trust
  • Accuracy is a purpose of the way data is collected. it is also a purpose of the transmission mechanism used by RDS (RDAP, port 43 or whatever we choose). but accuracy is not a purpose of the RDS itself.
  • Don't want to preclude the possibility that the RDS runs proactive checks on the accuracy of data - which isn't about providing access to the data per se
  • Considering possible text for a new purpose. One potential is "A purpose of the RDS is to provide an authoritative source of accurate data." But can the RDS ensure accuracy of data? Having a purpose of having accurate data is not the same as certifying accuracy.

Action #2: Staff to circulate call results as redline. All WG members to review redline and submit any further feedback on-list before next WG call.

4.  Confirm next meeting date: Wednesday 19 October at 05:00 UTC

 

Meeting Materials:

 

  • No labels