Next-Generation gTLD Registration
Directory Service (RDS) to replace WHOIS
ICANN57 F2F Meeting Slides
RDP PDP WG | ICANN57 | 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:
 Users/Purposes: Who should
have access to gTLD registration
data and why?
https://community.icann.org/x/oIxlAw
 Data Elements: What data
should be collected, stored, and
disclosed?
 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 gTLD
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-Phase1-FundamentalQs-SubQs-MindMap-2May 2016.pdf
This map was created as a tool to help the WG better understand and
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-Phase1-FundamentalQs-SubQs-MindMap-2May 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
Users/Purposes PRs
with Phase = 1
Subsets of DE PRs
Data Elements PRs
Data Elements PRs
with Phase = 1
Subsets of PR PRs
Privacy 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
FQ
OQ
UP
GA
DA
DE
PR
CX
CM
SM
CS
BE
RI
DE
12e
PR
FQ
12a&b
13
14
First
Initial
Report
Public
Comment
GA
15-16
DA
OQ
CX
CM
Foundational Question
Other Questions
Users/Purposes
Gated Access
Data Accuracy
Data Elements
Privacy
Coexistence
Compliance
System Model
Cost
Benefits
Risks
18
12c&d
SM
CS
Second
Initial
Report
19
Public
Comment
BE
RI
Rough Informal Consensus
Consensus
20
Final
Report
Phase 1
Formal Consensus per Charter IV
Task #s are taken from Work Plan @ https://community.icann.org/x/oIxlAw
| 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/E4xlAw
 Charter Questions and Key Inputs for each Question
 RDS-PDP-Phase1-FundamentalQs-SubQs-MindMap

PDP WG Work Plan: https://community.icann.org/x/oIxlAw
 Approach to consensus in deliberation of possible requirements

Phase 1 Outputs: https://community.icann.org/x/p4xlAw, including
 Draft 4: RDS PDP Initial List of Possible Requirements for gTLD
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/rjJ-Ag
| 19
To learn more
Thank You and Questions
Reach us at:
Email: [email protected]
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 gTLD 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 gTLD 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