NextGeneration g TLD Registration Directory Service RDS to

Next-Generation g. TLD Registration Directory Service (RDS) to replace WHOIS ICANN 57 F 2 F Meeting Slides RDP PDP WG | ICANN 57 | 3 November 2016

Agenda 1 2 3 Introductions & SOI Updates Accomplishments & Status Next Steps & Working Session 4 5 Action Items & Next Meeting Links to Meeting Materials | 2

WG Member Introductions and SOI Updates Agenda Item #1

RDS PDP WG: Accomplishments & Status Agenda Item #2

What have we accomplished so far? • Approved Work Plan, including • Approach to reach Consensus • Key Input Summaries for • Users & Purposes • Data Elements • Privacy • Initial Possible Requirements List (in progress), incorporating • Extracts from Key Inputs • Early Outreach responses • PDP Phase(s) • Dependencies • Codes and Keywords • Further materials to prepare for deliberations • Problem statement for this PDP WG • Representative set of example use cases • Registration data and directory service statement of purpose | 5

RDS PDP WG: Next Steps & Working Session Agenda Item #3

It’s now time to start deliberations Task 12. a: Deliberate on Possible Fundamental Requirements, starting with a first pass at deliberating on requirements for these three charter questions: v Users/Purposes: Who should have access to g. TLD registration data and why? https: //community. icann. org/x/o. Ixl. Aw v Data Elements: What data should be collected, stored, and disclosed? v Privacy: What steps are needed to protect data and privacy? | 7

Keeping in mind where we’re headed… Users and Purposes Who should have access to g. TLD registration data and why (for what purposes)? Gated Access What steps should be taken to control data access for each user/purpose? Registration Data Elements Privacy What data should be collected, stored, and disclosed? What steps are needed to protect data and privacy? Registration Data Accuracy What steps should be taken to improve data accuracy? Establishing a foundation to answer this question: Is a new policy framework and a next-generation system needed to address these requirements? | 8

Further detailed in the charter & issue report This Mind Map serves as a concise illustration of the fundamental questions and sub-questions detailed in the RDS PDP Charter and Issue Report: RDS-PDP-Phase 1 -Fundamental. Qs-Sub. Qs-Mind. Map-2 May 2016. pdf This map was created as a tool to help the WG better understand reach agreement on the fundamental questions to be addressed in phase 1 by illustrating inputs, dependencies, and sub-questions (expanded on next slide) | 9

We’ll start deliberating on three questions Iterating in a randomized manner RDS-PDP-Phase 1 -Fundamental. Qs-Sub. Qs-Mind. Map-2 May 2016. pdf | 10

By deliberating on possible requirements For example, consider these Data Element (DE) possible requirements QQ: Charter Question (e. g. , UP, DE, PR) D#: Source Document # R#: Unique Possible Requirement (PR) # (Ph)ase 1 / 2 / 3 (C)odes (K)eywords Phases, codes, and keywords can be used to select subsets for deliberation | 11

Using a randomized iterative approach 1. Sort possible requirements for phase 1 requirements only. 2. Randomly order the three questions: Users/Purposes, Data Elements & Privacy. 3. For the first round, start with the first randomly selected question, followed by the second, and then the third, discussing a subset of possible requirements, using the Prerequisites/Dependencies, Codes, and Keywords to select subsets for deliberation. 4. For the next round, rotate the order of questions so that the second becomes the first, the third becomes second, and the first becomes third, iterating on step 3. Subsets of UP PRs Users/Purposes PRs with Phase = 1 Subsets of DE PRs Data Elements PRs with Phase = 1 Subsets of PR PRs Privacy PRs with Phase = 1 Deliberate on questions in random order, rotating order in each iteration | 12

Proposed approach for selecting subsets • Codes may be used to select subsets for deliberation • Start with Alpha Order: Start deliberating on a subset of PRs that have Code = "A. " Continue with subsets for other Codes in alphabetical order (e. g. , AA, AB, AC, AD, B…), or as determined during deliberation. • Further filtering may help to organize deliberation on each subset • Dependencies: Begin deliberating on the PRs within each subset that have no dependencies. Continue by following the chain of inter-dependencies between PRs within that subset, so that continuing deliberations can build upon points of agreement. • Keywords: For subsets that are large or broad, apply Keywords to break into smaller subsets. • Charter Subquestions: Map the PRs within each subset to subquestions posed by the Mind Map, so that points of agreement can be applied to answer Charter Questions. | 13

For example, Data PRs with Code = “A” include Extracted from Draft 5 in-progress (code review still underway) Subset sizes vary significantly by Code and Question | 14

Approach to reach consensus in Phase 1 UP DE 12 e PR FQ 12 a&b GA DA OQ 12 c&d 13 FQ OQ UP GA DA DE PR CX CM SM CS BE RI 14 First Initial Report Public Comment 15 -16 CX CM SM CS 18 Second Initial Report Foundational Question Other Questions Users/Purposes Gated Access Data Accuracy Data Elements Privacy Coexistence Compliance System Model Cost Benefits Risks 19 Public Comment BE RI Rough Informal Consensus 20 Final Report Phase 1 Formal Consensus per Charter IV Task #s are taken from Work Plan @ https: //community. icann. org/x/o. Ixl. Aw | 15

As a starting point, for today’s meeting • We will cover all three charter questions in the following randomly-selected order: • Users and Purposes • Data Elements • Privacy • We will start by examining only the possible requirements within each of these subsets that have Code = “A” and no dependencies or pre-requisites • For each possible requirement, WG members may offer brief comments on conceptual merits or concerns (i. e. , not specific wording) • We will record a general sense of the room on level of support for that PR • As appropriate and time permitting, we may also examine additional possible requirements that appear to cover the same concept • Results of this initial pass will be captured for use in drafting recommendations to review, refine, and deliberate upon in upcoming WG calls and on the WG list • For each question (Users/Purposes, Data Elements, Privacy), we will examine all PRs without dependencies for that question before doing the same for the next question | 16

Confirm Action Items, Next Steps, Next Meeting Agenda Item #4

Links to Meeting Materials Agenda Item #5

To prepare for this session PDP WG Charter: https: //community. icann. org/x/E 4 xl. Aw Charter Questions and Key Inputs for each Question RDS-PDP-Phase 1 -Fundamental. Qs-Sub. Qs-Mind. Map PDP WG Work Plan: https: //community. icann. org/x/o. Ixl. Aw Approach to consensus in deliberation of possible requirements Phase 1 Outputs: https: //community. icann. org/x/p 4 xl. Aw, including Draft 4: RDS PDP Initial List of Possible Requirements for g. TLD registration data and directory services (Draft 5 underway) Draft Registration Data and Directory Service Statement of Purpose (work in progress) Additional info@ RDS PDP WG Wiki: https: //community. icann. org/x/rj. J-Ag | 19

To learn more Thank You and Questions Reach us at: Email: gnso-rds-pdp-wg@icann. org Website: http: //tinyurl. com/ng-rds | 20

Background on this PDP This PDP has been tasked with defining the purpose of collecting, maintaining and providing access to g. TLD registration data and considering safeguards for protecting that data, determining if and why a next-generation Registration Directory Service (RDS) is needed to replace WHOIS, and creating policies and coexistence and implementation guidance to meet those needs. The charter organizes this WG’s tasks into three phases | 21

During Phase 1, this WG will • Attempt to reach consensus on the following (at a minimum): • What are the fundamental requirements for g. TLD registration data? When addressing this, the PDP WG should consider, at a minimum, users & purposes, access, accuracy, data elements, and privacy • Is a new policy framework and a next-generation system needed to address these requirements? • If yes, what cross-cutting requirements must any next-generation RDS address, including coexistence, compliance, system model, and cost, benefit, and risk analysis requirements • If no, does the current WHOIS policy framework sufficiently address these requirements? If not, what revisions are recommended to the current WHOIS policy framework to do so? | 22