[gnso-rds-pdp-wg] IMPORTANT: Notes from RDS PDP WG Meeting - 18 July

Tue Jul 18 21:35:18 UTC 2017

Dear all,

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

To recap Action Items from today's call:

.        ACTION ITEM: Chuck Gomes to send discussion topics to list,
including remaining green (mostly-agreed) elements in preparation for next
week's call

.        ACTION ITEM: Leadership to develop poll for next week to confirm
understandings reached during this call on the data elements discussed
(Registrant Name, Registrant Organization, Registrant Country and Registrant
Email Address), to reveal level of agreement following clarification of
intent for collection (not display) of each data element. Staff to implement
poll; all WG members encouraged to participate in poll.

.        ACTION ITEM: Staff to develop a preliminary definition for
"Registrant Name" (Registrant) based on existing definition in the RAA, as
well as the discussion of this data element during today's call, which will
be subject to review by the WG

.        ACTION ITEM: Staff and/or Rod Rasmussen to provide an overview of
the EWG's contact paradigm to help the WG delve into this concept

Best regards,
Lisa

Notes RDS PDP WG Meeting - 18 July 2017:

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/SWfwAw>
https://community.icann.org/x/SWfwAw

1. Introductions and SOI Updates

.        Attendance taken from AC

.        SOI updates: Chuck Gomes has retired from Verisign, but will
perform consulting services for Verisign involving chairing this PDP in a
neutral capacity

2. Continue deliberation beyond "minimum public data set"

.        Charter Question: "What data should be collected, stored and
disclosed?"

.        See expanded handout and poll results:
https://community.icann.org/x/SWfwAw 

a. Review agreed approach and general comments: "Concentrate on the set of
data elements that may be collected and possibly displayed in the RDS. That
is, review the entire table of proposed elements, deciding what to
delete/add."

.        Roll-up for all results of questions 2 - 39 are presented, except
for question 40, which is addressed separately

.        Color-coding and support column meant to assist in identifying
level of support for each data element

.        Numbers in Support column calculated by the sum of views expressed
for each data element with weighted responses: Strongly Agree: 2, Agree: 1
Neutral/Unsure: 0, Disagree: -1 and Strongly Disagree: -2

.        Results also displayed in graphical form on page 6 of the document,
with color-coding displaying the levels of support, explained in a legend on
the same page

b. Deliberate on rationale for data elements that are broadly supported:

.        The scope of registration data elements is those that ICANN defines
and has control over

.        Some comments indicated an assumption that inclusion implies
display/access. That was not the intent. WG agreed to focus on the set of
data elements to be included in the RDS first, before deliberating on
display/access in subsequent discussions

.        RDS is a repository of data elements that may or may not be
accessible under yet-to-be-specified conditions (i.e., may result in
multiple levels of access), but this is subject to further consideration and
discussion by the WG

Registrant Name

.        Poll results: 27 Agree, 2 Neutral/Unsure, 6 Disagree

.        Registrant Name is a clearly-defined existing WHOIS data element. 

.        Per 2013 RAA: Registrant is the entity that has acquired the right
to use the Internet resource (here, Domain Name)

.        Registrant Name needs to be considered in a broader context than
domain used by websites (example: use of a domain name for email, registrars
need to know who their clients are, etc...)

.        Privacy is a policy consideration on how Registrant Name is
processed (to be determined), but does not preclude the value of collecting
it as a data element - need to disentangle the need for a data element in
the database versus what will be collected (example: this data element may
be populated by a Registrar, Privacy/Proxy (P/P) service provider, or the
Registrant itself, depending on circumstances)

.        If Registrant Name data element is filled with the name of a Proxy
service provider, does that create some overlap or redundancy with
Privacy/Proxy Contact data elements? Note: P/P Contact contains contact
details for the P/P, not just the provider's name. Also, for
Privacy-registered domain names, the Registrant Name does not carry the
provider's name.

.        Should data element be Registrant Name or Organization or P/P
provider name?

.        Regardless of which actor's data is collected for this data
element, it will be populated, whether by the name of a person registering
the domain name, the name of an organization registering the domain name, or
a Proxy service provider registering a domain name on behalf of someone else

.        Data element could collect data that does not identify a specific
person (such as "domain admin"), connected to real contact data (such as an
email address to reach the domain admin), but does not necessarily need to
be a real person's name

.        Note there is also a Registrant Contact ID - a unique numeric value
assigned to each Registrant by the Registrar - but it didn't have as strong
support and so isn't displayed on this page of poll results

.        Knowledge of the identity of a domain name Registrant is necessary
in scenarios such as disputes resulting during a domain name transfer, or if
a registrar ceases its operation (data would be accessible via a data escrow
provider)

.        Regarding comments from those who disagreed, we are starting with
collection and not display. For many purposes, Registrant Name is necessary,
even if it is not displayed

.        Suggestion to rename this data element to "Registrant Label" or
simply "Registrant" - could be a name, a pseudonym, an organization, a P/P
provider - whatever it is, this data element needs to be in the RDS,
regardless of whether it will be displayed or not

.        Suggestion to rename the data element may require a definition of
what the data element is meant to represent - will slow down the process,
especially if renaming is repeated with other data elements

.        Suggestion to determine what contact information is required as
data elements in the RDS, then associate roles for each contact data
element. For example, the same email address might be used to contact the
Registrant and to resolve technical issues - those would be two roles using
that email address (or contact)

.        ACTION ITEM: Staff to develop a preliminary definition for
"Registrant Name" (Registrant) based on existing definition in the RAA, as
well as the discussion of this data element during today's call, which will
be subject to review by the WG

Registrant Organization

.        Poll results: 27 Agree, 2 Neutral/Unsure, 6 Disagree

.        This data element may not be applicable to every domain name, if
there is no Organization associated with the Registrant

.        According to the 2013 RAA: For the Registrant, Admin and Tech
contact fields requiring a "Name" or "Organization", the output must include
either the name or organization (or both, if available).

.        Collecting this data element may therefore be optional.

.        Another option may be to collect this data element, but not display
it publicly

Registrant Country

.        Poll results: 28 Agree, 2 Neutral/Unsure, 5 Disagree

.        Comments indicating that data should not be collected due to
privacy concerns should be addressed as agreements whether or not to
display/access this data - does not obviate the need to collect it

.        Several comments cite "Registrant Country" as important to identify
jurisdiction

.        "Registrant Country" may be useful in the context of multinational
corporations with operations in different countries or TLDs which are not
permitted in certain jurisdictions

.        For example, location of technical staff registering a domain name
in a multinational corporation may be what determines the Registrant Country
- or the multinational corporation's head office location may determine
Country

Registrant Email Address

.        Poll results: 28 Agree, 3 Neutral/Unsure, 4 Disagree

.        Email address is the primary method of contact between a Registrar
and Registrant - necessary for collection

.        Email address also necessary for a dispute provider to contact a
Registrant

.        Is it necessary to collect email addresses, or should choice of
preferred contact method be optional? Should it only be necessary to have
the ability to contact the Registrant (possible qualifier during future
consideration/discussion)?

.        Useful to consider what the preferred method of contact for each
Registrant is, however need to consider how that would affect existing
policies in place

.        Whois accuracy reporting focuses on the ability to contact a
Registrant

.        Proposed Question: Is collection of Registrant contact information
required for the RDS? (as opposed to collecting specific types of contact
information)

.        Important to consider contact redundancy solutions, when one
contact does not work - alternative options may be required

.        Qualification of context of collection of Email Address to be
clarified

.        Should collection of Email Address be optional if other means of
contact are more preferable by the Registrant?

.        Do other methods of contact provide redundancy solutions in the
event of a failure to contact a Registrant using primary preferred method?

.        How will existing policies be affected?

Admin Contact and Contact ID (deferred)

Technical Contact and Contact ID

.        Do WG members understand what purpose this contact in meant to
serve? Hasn't been useful in the past, and has often been a redundant
element, which mirrors the Admin Contact and/or Registrant details

.        Members of the IPC indicated that this is one of the data elements
that they use - IPC members should clarify how this data element is useful
during the discussion

.        The WG needs to define (provide consistent definitions) for what is
intended for each data element, and provide guidance on collection and
disclosure requirements for each defined data element

.        WG members to develop consistent definitions for the various data
elements, which are to be collected, generated or displayed (this is part of
our charter)

.        In addition to defining data elements, it should be clear what each
element is referring to. For example, some resellers have default setting
that populate Technical Contact data elements with the reseller's own data

.        Potentially less useful data elements might need to be optional for
collection - other contacts, such as hosting provider, could be more useful

Privacy/Proxy Provider Contact and Contact ID (deferred)

Reseller (deferred)

Registrar Abuse Contact Email Address (deferred)

Registrar Abuse Contact Phone (deferred)

URL of Internic Complaint Site (deferred)

Original Registration Date

.        Does this data element refer to the first time this domain name was
ever registered, or does it refer to the date on which the current
registrant registered it - different contexts may have different uses, or
create incorrect assumptions

.        This date element was proposed by the EWG with the following
definition: "The date on which this domain name was first registered. This
is different than the creation date since the creation date picks up the
latest time the domain name was registered; it is possible that the domain
name was previously registered and subsequently deleted multiple times. The
Original Registration Date denotes the first date that the domain name was
ever registered."

.        This may be useful for copyright and trademark issues; purposes
listed in the EWG report included DN control, business DN purchase/sale, DNS
research, regulatory and contractual enforcement, and criminal
investigation/DNS abuse mitigation

c. Deliberate on deletion of data elements that are largely unwanted (time
permitting) (deferred)

d. Deliberate on remaining data elements (time permitting) (deferred)

e. Deliberate on new data elements (deferred)

.        Continue discussion of new data elements suggested in Q40, possibly
using a poll for input on viability of these new elements being collected
for inclusion in the RDS

3. Confirm action items and proposed decision points

ACTION ITEM: Chuck Gomes to send discussion topics to list, including
remaining green (mostly-agreed) elements in preparation for next week's
call. All WG members are invited to participate in focused on-list
discussion of these topics.

ACTION ITEM: Leadership to develop poll for next week to confirm
understandings reached during this call on the data elements discussed
(Registrant Name, Registrant Organization, Registrant Country and Registrant
Email Address), to reveal level of agreement following clarification of
intent for collection (not display) of each data element. Staff to implement
poll; all WG members encouraged to participate in poll.

ACTION ITEM: Staff to develop a preliminary definition for "Registrant Name"
(Registrant) based on existing definition in the RAA, as well as the
discussion of this data element during today's call, which will be subject
to review by the WG

ACTION ITEM: Staff and/or Rod Rasmussen to provide an overview of the EWG's
contact paradigm to help the WG delve into this concept

4. Confirm next meeting date: 25 July 16.00 UTC

Meeting Materials: (all posted at https://community.icann.org/x/SWfwAw)

.        Expanded Handout on Poll for Data Elements
<https://community.icann.org/download/attachments/66086729/28JunePoll-DataEl
ements-ExpandedHandout.pdf?version=1&modificationDate=1499549422000&api=v2>
- 28 June

.        Analysis of Survey Results
<https://community.icann.org/download/attachments/66086729/AnalysisResults-P
oll-from-28JuneCall.pdf?version=1&modificationDate=1500320760000&api=v2> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20170718/0436127f/attachment-0001.html>