[gnso-rds-pdp-wg] IMPORTANT: Notes from RDS PDP WG Meeting - 27 February 2018

Tue Feb 27 23:30:46 UTC 2018

Dear all, 

Below, please find notes from today’s RDS PDP WG meeting.

To recap Action Items from today’s call: https://community.icann.org/x/oAu8B

Action:  DT Coordinators to send first cut of draft answers to DTs by 28 February.

Action:  DT members to review/discuss on DT email list this week, aiming to provide output by 5 March but no later than 7 March.  List of DTs and members currently:   https://community.icann.org/pages/viewpage.action?pageId=71602347

Action: DTs to provide status update during the next WG Call (Tuesday 6 March at 17:00 UTC). 

Action: For those not assigned to a DT, if you would like to be assigned and can commit to working on this assignment over the next week, send email to staff (Marika, Lisa or Caitlin).

Action: WG members to review outputs of DTs prior to ICANN 61 Saturday, 10 March F2F (from 8:30 – 12:00 Local Time).

Kind regards,

Caitlin

Action Items and Notes from RDS PDP WG Call – 27 February 2018

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.

1. Roll Call/SOI Updates

Wiki page: https://community.icann.org/display/gTLDRDS/2018-02-27+Next+Gen+RDS+PDP+Working+Group
Call Handout: https://community.icann.org/display/gTLDRDS/2018-02-27+Next+Gen+RDS+PDP+Working+Group?preview=/79432608/79437204/Handout-27February-RDSWGCall.pdf

2. Brief recap of WG's iterative approach to discussion of charter questions

Link to recap: Agenda Item 2 - Recap of approach and past year
WG's Charter splits work into three phases.  WG is currently in Phase 1, and as such, is tasked with reaching consensus on requirements for the future RDS policy. If WG agrees that a new RDS policy framework and system are needed to support phase 1 requirements, the WG will continue on to define those policies and provide implementation guidance in phases 2 and 3.
The WG’s charter tasks it with answering several foundational questions concerning the purposes for registration data, who should be permitted to access that data and how, and measures required for data protection, privacy, and accuracy.
At times, some have asked why the WG is focusing only on privacy or data or purposes, and have suggested we answer a different charter question “first.” While it may appear – especially to newcomers - as though the WG is looking at questions in the “wrong” order, the answer is that we are taking an iterative approach to examine ALL of these tightly-interdependent questions by moving from one question to another and back again throughout deliberation.
For those relatively new to the WG, the Leadership Team reminds you that reading the charter and catching up on past meetings and progress is not just expected but essential to effective participation.
For long-time WG members, the Leadership Team encourages everyone to reread the Phase 1 working draft and related documents to refresh your memory of past agreements and avoid repeating past discussions.
Anyone looking for a refresher on the WG’s charter questions and phased iterative approach may wish to replay the newcomer webinar, linked to the WG’s wiki landing page. If repeating that webinar live would be helpful, that can be arranged.
For more information and background on the iterative approach taken by the WG, please refer to this document: https://community.icann.org/display/gTLDRDS/2018-02-27+Next+Gen+RDS+PDP+Working+Group?preview=/79432608/79437251/HistoryRecap-27FebCall.pdf

Charter link: https://community.icann.org/x/E4xlAw

Phase 1 outputs page: https://community.icann.org/x/p4xlAw

Beginner’s Tutorial: https://participate.icann.org/p73xek0tdqa/

3. Introduce Drafting Team assignment

Refer to Slides 3-4 of Handout and assignment as described in https://community.icann.org/download/attachments/79432608/Drafting%20Team%20Assignment%2026%20Feb.pdf
Based on the discussion last week, and in preparation for ICANN 61, the Leadership Team suggests that purpose drafting teams re-examine their outputs to answer the questions on Slide 3.  (please refer to 3a in the notes for the questions).
In answering the questions, DTs should not feel constrained by current fields in WHOIS. DTs are asked to think conceptually and describe entities to be identified or contacted, the objectives for doing so, and the expected roles and responsibilities of entities being identified or contacted.
Are DTs asked to look only at agreed purposes or all proposed purposes? All
Are purposes limited to proposed purposes? No, but we’ll start with those already proposed
Are purposes assumed to be legitimate? Should we cover only agreed purposes? No, we are laying the foundation for effective deliberation of several possible purposes at our ICANN61 F2F. 
What does ‘entity’ refer to? In questions below, “entity” = party associated with a DN registration who may need to be identified or contacted for the possible purpose. 

a. Provide questions to be answered by drafting teams

                1. Who associated with a DN registration needs to be identified and/or contacted for each purpose?

                2. What is the objective achieved by identifying and/or contacting each of those entities? 

                3. What might be expected of that entity with regard to the domain name?  

b. Review due dates and process to complete answers as input to ICANN61

Action: Each DT should be prepared to provide status at next WG meeting (Tuesday 6 March at 17:00 UTC)
Action: Final draft of answers should be provided to the full WG mailing list ideally by 5 March (and no later than 7 March)
Action: If WG members would like to join a DT, please send a message to Marika, Caitlin, or Lisa.

c. Illustrate how to answer questions on Slide 3 of Handout by examining one purpose: technical issue resolution

QUESTION: Who associated with the DN registration needs to be identified and/or contacted for the purpose of technical issue resolution? 

Technical Issue Resolution was previously defined by DT1; see:
Technical Issues Resolution PDF and DOC

WG feedback: 

In the absence of a contact designated to handle technical issue resolution, it would be the registrant service as a point of contact for technical issue resolution.
What is the entity (organization or individual) expected to do? What benefit would there be for a party to initiate contact with this entity? For example, with respect to technical issue resolution, is the party making contact trying to alert the people managing the domain that they have a problem that would be to their benefit to resolve or is the party making contact trying to get attention to a problem that it has?
The entity you want to reach for technical issue resolution may be the account holder because they have control over the domain name registration. However, this may not always be the case (for example, the account holder may be a proxy, not the user of the domain name).

QUESTION: What is the objective achieved by identifying and/or contacting each of those entities?

An objective would be having the ability to contact someone associated with the domain name registration who can quickly surmise and solve technical issues associated with the domain name such as botnets, email storms, etc. 
It may be unreasonable to put obligations or a certain bar of competency on an entity who registers a domain name.  For instance, the ability to contact the entity may be enough, without a contractual obligation on the entity to take action once notified. 
Contactability is important for a variety of purposes. Entities who differentiate different contacts (that is, provide more than one contact for registrant, tech contact, and admin contact) are usually large companies and/or those contacts may be filled in by registrars.  
Tech contact was there to have someone to reach out to for any domain name problem.  For registrant contact, that is the entity who registered and owns the domain name. 
Note Rough Consensus agreement # 36: Purpose-based contact (PBC) types identified (Admin, Legal, Technical, Abuse, Proxy/Privacy, Business) must be supported by the RDS but optional for registrants to provide.
If an entity does wish to respond to contact attempts, that may be its prerogative, irrespective of the reason for the contact attempt.  To the extent entities are not contactable, larger players may already know who to contact; they may or may note depend on WHOIS.  Smaller players and outsiders will be impacted more if contact information is not provided through RDS.  Privacy is important, but so is security and stability -- if we achieve privacy but break the internet, that is not a desirable outcome.
There needs to be at least one form of contact for a domain name registration (refer to WG agreements below). Contactability may be a self-evident obligation for someone who has a domain name registration. 
We should start from a clean slate and lay out all of the foundation and reasoning as we get to whatever system we want to end up with.  Even though we have this technical resolution purpose, why are we defining other purposes?  Are purposes an obligation we're looking to put on a registrant? What is the objective of defining roles and responsibilities associated with technical issue resolution? 
Refer to WG Agreement 30. At least one element identifying the domain name registrant (i.e., registered name holder) must be collected and included in the RDS.
Refer to WG Agreement 31. Data enabling at least one way to contact the registrant must be collected and included in the RDS.
In Q1, there is a concept of identifying and contacting.  In some purposes, it may be sufficient to identify, and no contact is necessary.  DTs may want to separate the two when they begin drafting answers to the questions.
It may be useful for DTs to describe the benefit to the entity being identified or contacted, as well as the benefit to the party requesting registration data to identify or initiate contact.

4. Confirm action items & next steps 

Action:  DT Coordinators to send first cut of draft answers to DTs by 28 February.

Action:  DT members to review/discuss on DT email list this week, aiming to provide output by 5 March but no later than 7 March.  List of DTs and members currently:   https://community.icann.org/pages/viewpage.action?pageId=71602347

Action: DTs to provide status update during the next WG Call (Tuesday 27 February at 17:00 UTC). 

Action: For those not assigned to a DT, if you would like to be assigned and can commit to working on this over the next week, send email to staff (Marika, Lisa or Caitlin).

Action: WG members to review outputs of DTs prior to ICANN 61 Saturday, 10 March F2F (from 8:30 – 12:00 Local Time).

5. Confirm next meeting: Tuesday 6 March at 17:00 UTC

ICANN 61 F2F: Saturday 10 March from 8.30 - 12.00 Local Time

ICANN 61 F2F: Wednesday 14 March from 15.15 - 18.30 Local Time

Meeting Materials: https://community.icann.org/display/gTLDRDS/2018-02-27+Next+Gen+RDS+PDP+Working+Group

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20180227/ce291f20/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4621 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20180227/ce291f20/smime-0001.p7s>