[gnso-rds-pdp-wg] IMPORTANT: Action Items and Notes from GNSO Next-Generation RDS PDP WG Call - 12 September 2017

Tue Sep 12 21:05:26 UTC 2017

Dear Working Group Members,

Below are the action items and notes from today’s WG call. The action items, notes, recording and meeting documents from today’s call have also been posted on today’s meeting wiki page here: https://community.icann.org/x/ZmfwAw. The transcripts will be posted on the same page, when they are available.

Thanks.

Amr

Action Items:

1.     Any WG member who wishes to volunteer to draft possible WG agreements from this call on the collection of Registrant Phone + Phone Ext as well as Registrant Postal Address should volunteer on the mailing list in the next 24 hours (Volunteers so far: Stephanie Perrin)
2.     Staff to develop a poll to confirm Proposed WG Agreements on the RDS supporting the Registrant Phone + Phone Ext and the Registrant Postal Address data elements
3.     Staff to distribute the list of previously agreed to purposes for which gTLD registration data should be collected to the WG mailing list

Notes:
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/ZmfwAw

1) Roll Call/SOI Updates

  *   No updates to SOIs declared

2) Continue deliberation on Data Elements beyond MPDS
   a) Charter Question: "What data should be collected, stored and disclosed?" focusing on identifying set of data required in the RDS first
   b) How results from 5 September call<https://community.icann.org/x/YmfwAw> will be used

  *   10 responses received, will be used when deliberation resumes on Registrant Type after receipt of legal analysis
  *   Results posted on wiki as usual - see Phase 1 outputs page for all poll results and WG agreements to date

   c) Continue deliberation on remaining data elements (see handout<https://community.icann.org/download/attachments/66086758/RDSPDP-Handout-For12SeptCall.pdf>), starting with:
Registrant Postal Address Data Elements: Registrant Street Address, City, State/Province, and Postal Code
Registrant Phone + Registrant Phone Ext

  *   Does anyone think the Registrant Postal Address and Phone should NOT be supported by the RDS (regardless of collection policy)?
  *   No objections raised by those on the call to the RDS supporting Registrant postal address and phone data elements (the system should have the capacity to support those data elements)

Proposed WG Agreement (to be confirmed by poll): The RDS must support Registrant Postal Address.
Proposed WG Agreement (to be confirmed by poll): The RDS must support Registrant Phone Number.

ACTION ITEM: Staff to develop a poll to confirm Proposed WG Agreements on the RDS supporting the Registrant Phone + Phone Ext and the Registrant Postal Address data elements

  *   Slide 3 of handout lists some related WG agreements thus far (e.g., requiring country code)
  *   Slide 4 lists these data elements as currently required by the RAA 2013

  *   Next question: Should Registrant Postal Address and Phone be mandatory for Registrants to provide?
     *   Postal Address and Phone are required in some legal proceedings and so collection would be required to satisfy those purpose(s)
     *   There may be some conflicting requirements posed by data protection laws that prevent collection/storage of these elements for some registrations - independent legal analysis may provide input to this
     *   When a registrar collects these data elements, that does not necessarily imply these data elements end up in the RDS (for example, registrant address may be collected but a privacy service address may end up in the RDS)
     *   If data is collected, even if data is not to be displayed, it could end up in the RDS - for example in P/P, there may be situations when address is needed for P/P relay to Registrant or proxy customer even if address is not disclosed
     *   If there is a failure at a provider, escrowed data may be needed, but that isn't the same as putting the data in the RDS. Registrar may have the "real" address and be obliged to do a relay - but that still may not require the RDS to store this data
     *   See 28 June poll question results on whether Registrant Street Address (as defined by the 2013 RAA) should be included in RDS data elements - roughly half agreed but many were unsure and the rest disagreed, see comments for rationale for/against support
     *   Also see 28 June poll question results on Registrant Phone + Phone Ext
     *   Chat comment: I'm happy with data minimalism. but it seems that contact of people for legal purposes is part of the point of having a registry
     *   Slide 10 depicts possible alternative framing for WG agreements on Registrant Postal Address and/or Registrant Phone
     *   Does slide 10 accommodate privacy/proxy registered domain names? Yes, Registrant Address and Phone fields are currently filled in for both privacy and proxy registrations
     *   When we say "collection" we should say "collection for inclusion in the RDS" - given this is our charter, can it be assumed?
     *   Do we need to specify forms of contact that are required, or that contactability is needed? If we are allowing an opportunity for contact and communication models, we need to address the latter before deciding what to require for Registrant contact
     *   We're looking at increasing contactability and why we need contactability. To this end, postal address is needed within the RDS for legal purpose. A telephone number is needed for time-sensitive purposes. An email address is needed for day to day contact but doesn't satisfy those other purposes.
     *   Need to consider the ramifications of not collecting or providing a data element, depending upon purposes - for example, UDRP process would shut down a domain immediately if there was no postal address permitting contact
     *   Note the phrasing in 2a/b refers to contact roles - this was used in the WG’s previous agreement on email to allow contact roles to determine what data elements are required for each role. For example, postal address might be required for a contact used for legal purposes
     *   Would a drafting team like to look at thoughts raised in today's call on these data elements and come back to WG with some proposed WG agreements for full WG consideration?

ACTION ITEM: Any WG member who wishes to volunteer to draft possible WG agreements from this call on the collection of Registrant Phone + Phone Ext as well as Registrant Postal Address should volunteer on the mailing list in the next 24 hours (Volunteers so far: Stephanie Perrin)

d) Time permitting, continue with remaining data elements (see handout<https://community.icann.org/download/attachments/66086758/RDSPDP-Handout-For12SeptCall.pdf> - Slide 11)

  *   Are there WG members on the call who do not agree that the remaining data elements should not be supported by the RDS?
     *   Is it premature to ask this question, as these data elements are not currently included in today's WHOIS, and not required by the 2013 RAA?
     *   Instead, the WG should consider the goal of adding each new data element to the RDS (i.e., why would the data element be useful?)
  *   Starting at the top of the table on Slide 11, would it be helpful for the RDS to support Registrant Contact ID (Registry Registrant ID), Registrant Contact Validation Status, Registrant Contact Last Updated Timestamp and/or Registrant Company Identifier? – Note that the Registrant Contact Validation Status, Registrant Contact Last Updated Timestamp and Registrant Company Identifier are data elements that are not currently included in the 2013 RAA
     *   Registrant Contact Validation Status: Presumption that Role-Based Contacts would be validated - need to deliberate on contact validation and then confirm what this data element represents before discussing whether it is desirable for the RDS to support it
     *   It would not appear that #31 (Server Status) is impacted by data protection laws
     *   Difficulty in evaluating these fields may be due to not reaching an agreement on purposes to include them in the RDS - additionally, need to identify the purpose requirements of the RDS to understand whether the RDS supporting any proposed new data elements satisfies those requirements
     *   Suggestion to provide a briefing on previously developed purposes during next week's call as a refresher, to continue the discussion on purposes for registration directory services and data, before deliberating on additional data elements to enable purposes the WG recommends be treated as legitimate

ACTION ITEM: Staff to distribute the list of previously agreed to purposes for which gTLD registration data should be collected to the WG mailing list

4) Confirm action items and proposed decision points

1.     ACTION ITEM: Any WG member who wishes to volunteer to draft possible WG agreements from this call on the collection of Registrant Phone + Phone Ext as well as Registrant Postal Address should volunteer on the mailing list in the next 24 hours (Volunteers so far: Stephanie Perrin)
2.     ACTION ITEM: Staff to develop a poll to confirm Proposed WG Agreements on the RDS supporting the Registrant Phone + Phone Ext and the Registrant Postal Address data elements
3.     ACTION ITEM: Staff to distribute the list of previously agreed to purposes for which gTLD registration data should be collected to the WG mailing list

Proposed WG Agreement (to be confirmed by poll): The RDS must support Registrant Postal Address.
Proposed WG Agreement (to be confirmed by poll): The RDS must support Registrant Phone Number.

5) Confirm next WG meeting (Wednesday 20 September at 05.00 UTC)

Meeting Materials:

  *   RDSPDP-Handout-For12SeptCall.pdf<https://community.icann.org/download/attachments/66086758/RDSPDP-Handout-For12SeptCall.pdf?version=1&modificationDate=1505150503000&api=v2> (identifies next data elements for deliberation)
  *   KeyConceptsDeliberation-WorkingDraft-5Sept2017.pdf<https://community.icann.org/download/attachments/66086754/KeyConceptsDeliberation-WorkingDraft-5Sept2017.pdf?version=1&modificationDate=1505070069985&api=v2> and DOC<https://community.icann.org/download/attachments/66086754/KeyConceptsDeliberation-WorkingDraft-5Sept2017.docx?version=1&modificationDate=1505070086484&api=v2>
  *   5 September Call poll  (closed COB Saturday 9 September)
     *   Link to participate: https://www.surveymonkey.com/r/DKQDSQ7
     *   PDF of Poll Questions:Poll-from-5September-Call.pdf<https://community.icann.org/download/attachments/66086754/Poll-from-5September-Call.pdf?version=1&modificationDate=1504667959000&api=v2>
     *   SurveyMonkey Summary Poll Results: SummaryResults-Poll-from-5SeptCall.pdf<https://community.icann.org/download/attachments/66086758/SummaryResults-Poll-from-5SeptCall.pdf?version=1&modificationDate=1505068909000&api=v2>
     *   SurveyMonkey Raw Data Poll Results: RawDataResults-Poll-from-5SeptCall.zip<https://community.icann.org/download/attachments/66086758/RawDataResults-Poll-from-5SeptCall.zip?version=1&modificationDate=1505068924000&api=v2> and XLS<https://community.icann.org/download/attachments/66086758/RawDataResults-Poll-from-5SeptCall.xlsx?version=1&modificationDate=1505068940000&api=v2>
     *   Annotated Survey Results: AnnotatedResults-Poll-from-5SeptCall.pdf<https://community.icann.org/download/attachments/66086758/AnnotatedResults-Poll-from-5SeptCall.pdf?version=1&modificationDate=1505068955000&api=v2>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20170912/1721b4cf/attachment-0001.html>