[gnso-rds-pdp-wg] IMPORTANT: Notes from RDS PDP WG Meeting - 5 December
Lisa Phifer
lisa at corecom.com
Wed Dec 6 00:32:32 UTC 2017
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/MAByB
WG Agreement: The following information is to be collected for the purpose
of Technical Issue Resolution associated with Domain Name Resolution:
· Technical Contact(s) or (if no Technical Contact is provided)
Registrant Contact(s),
· Nameservers,
· Domain Status,
· Expiry Date and Time,
· Sponsoring Registrar.
Action: Staff to record polled statement as rough consensus WG Agreement in
working document, including footnote noting that a possible need for Tech
Contact AND Registrant Contact (rather than Tech Contact OR Registrant
Contact) will be further deliberated later, as data element agreements are
refined.
Possible WG Agreement: DN Management is a legitimate purpose for collecting
some registration data, based on the definition supplied by DT2 (and/or the
extended definition).
Action: Staff to develop a poll on the above possible WG agreement; all WG
members encouraged to participate in the poll no later than COB Saturday 9
December.
Best regards,
Lisa
Action Items and Notes from RDS PDP WG Call – 5 December 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.
1. Roll Call/SOI Updates1. Roll Call/SOI Updates
· Meeting Materials: <https://community.icann.org/x/MAByB>
https://community.icann.org/x/MAByB
· Call Handout:
<https://community.icann.org/download/attachments/74580016/Handout-5Dec-RDSW
GCall.pdf>
https://community.icann.org/download/attachments/74580016/Handout-5Dec-RDSWG
Call.pdf
· No SOI updates given
2. Complete deliberation on Technical Issue Resolution as a legitimate
purpose
a. Review
<https://community.icann.org/download/attachments/74580016/AnnotatedResults-
Poll-from-29NovemberCall.pdf?version=1&modificationDate=1512408284000&api=v2
> poll results for Technical Issues associated with DN Resolution
· Slide 3 - overview of agreements thus far on Technical Issue
Resolution associated with DN Resolution
· Slide 4 - Poll Results on the proposed WG Agreement: The following
information is to be collected for the purpose of Technical Issue Resolution
associated with Domain Name Resolution:
o Technical Contact(s) or (if no Technical Contact is provided) Registrant
Contact(s),
o Nameservers,
o Domain Status,
o Expiry Date and Time,
o Sponsoring Registrar.
· Rough consensus on the above WG Agreement, with 87-100% support for
listed data
o Data with 100% support for this purpose:
§ Nameservers
§ Domain Status
§ Sponsoring Registrar
o Data with rough consensus but minority disagreements:
§ 96%: Technical Contact(s) or (if no Technical Contact is provided)
Registrant Contact(s)
§ 96%: Expiry Date and Time
§ 87.5%: Registrant Contact(s)
· Discussion of Comments
o Comment 1: Would the party resolving technical issues associated with DN
resolution need to know the physical location of the Tech Contact? As a
piece of identifying information? For example, sometimes knowing what
country someone is in will allow me to gauge when I'm likely to get a
response
o Note related WG Agreement 28. Registrant Country must be included in RDS
data elements; it must be mandatory to collect for every domain name
registration.
o Comments 2 & 5: Is Registrant Contact needed for THIS purpose,
regardless of whether Tech Contact is provided? In many cases, person with
issue wants to hear from party responsible for DN, not just Tech Contact -
and Tech Contact may not have authority to resolve some problems. Tech
Contact designated varies, ranging from IP admin to registrar to ISP to
registrant themselves - if Tech Contact cannot resolve issue, you need
ability to reach Registrant as well.
o Proposal: Add note to WG Agreement noting AND instead of OR may be
preferable to some and requires further deliberation.
o Comment 4: Will referring to contacts with labels used for data elements
today instead of "roles" constrain thinking about role-based contacts? For
example, refer to "Tech Contact Role" rather than "Tech Contact(s)"
o Note: May have multiple technical persons spread over multiple
locations, what we are looking for is the name of the person who directs
technical operations over the domain space
o Comment 6: Would Updated and Created Date be useful as well for this
purpose? Note that those two elements are already part of MPDS and so
available but perhaps not required for this purpose?
b. Finish deliberation on Data Elements needed for Technical Issue
Resolution
· See above discussion
· Note: Deliberate later on data access and users for Technical Issue
Resolution
WG Agreement: The following information is to be collected for the purpose
of Technical Issue Resolution associated with Domain Name Resolution:
· Technical Contact(s) or (if no Technical Contact is provided)
Registrant Contact(s),
· Nameservers,
· Domain Status,
· Expiry Date and Time,
· Sponsoring Registrar.
Action: Staff to record polled statement as rough consensus WG Agreement in
working document, including footnote noting that a possible need for Tech
Contact AND Registrant Contact (rather than Tech Contact OR Registrant
Contact) will be further deliberated later, as data element agreements are
refined.
3. Start deliberation on
<https://community.icann.org/download/attachments/74580010/RDS%20WG%20DT2%20
Draft%20edits%201113.pdf> Domain Name Management as a legitimate purpose
· Slide 6 - recall our building block approach where we first
deliberate if a purpose is legitimate for collecting any registration at
all, and second we deliberate on data required (essential not nice to have)
for that purpose.
· This does not preclude additional purposes being agreed as
legitimate for the same or other data, or this purpose from having access to
data collected for another purpose.
a. Intro by DT2 and opportunity for clarifying questions
· Definition developed by DT2:
o Domain Name Management: Information collected to create a new domain
name registration and ensuring that the domain registration records are
under the control of the authorized party and that no unauthorized changes,
transfers are made in the record.
· Slides 7-11 present list of tasks, users, and data elements needed
for THIS purpose of DN Management.
· Clarifying questions:
· Does Task 3 (manage a set of DNs) include a company that wants to
get a list of DNs they have registered or control?
o Probably yes.
b. Deliberate on DN Management as a legitimate purpose for collecting some
registration data
· Is DN Management a legitimate purpose for collecting some
registration data? (noting we'll deliberation on which data in agenda item
c)
· Note that criteria listed on slide 11 are questions that may help
the WG deliberate but are not themselves an agreed list of criteria for
legitimacy
· WHY is DN Management a legitimate purpose?
o Needed to manage domain names that are registered and controlled using a
distributed system.
o Distributed operation requires a place where people can register their
control over namespaces that are subordinate to gTLDs.
· How does DN Management support ICANN's Mission?
o Refer to ICANN's Mission Statement: Section 1.1 of Bylaws:
o <https://www.icann.org/resources/pages/governance/bylaws-en>
https://www.icann.org/resources/pages/governance/bylaws-en
o Excerpts from Bylaws can be found on Call Handout Slides 11-13
· Is this purpose conflating ownership and control of the domain
name?
o From chat: Not sure how you legitimately manage a domain without
controlling it.
o Should this be split into domain name registration vs. domain name
control (following registration)?
o May be related to designation of different contact roles - Registrant
vs. Admin Contact - but not necessarily different purposes but one
integrated purpose
o Will aggregating this into a single purpose make it hard to deliberate
on reasons for collecting specific data elements?
o Or will deliberation on each data element need to identify whether the
data element is needed for registration, for control, or both?
· Possible alternative (extended) definition:
o Information collected to create a new domain name registration, enabling
management of the domain name registration, and ensuring that the domain
registration records are under the control of the authorized party and that
no unauthorized changes, transfers are made in the record. (underlined text
added to the drafting team's definition)
· The drafting team started with the following definition found in
the EWG Report:
o DN Control purpose includes: Creating, managing and monitoring a
Registrant’s own domain name (DN), including creating the DN, updating
information about the DN, transferring the DN, renewing the DN, deleting the
DN, maintaining a DN portfolio, and detecting fraudulent use of the
Registrant’s own contact information.
· General suggestions about process:
o Drafting Teams were good at developing text in between meetings. we may
wish to revisit some derivative of that process on an ongoing basis
o We explore where we agree, and examine (in drafting teams) why we
disagree when we disagree (that might help)
o When doing the poll: can the EWG definition be included even if just for
reference?
o Add new definitions as they are agreed upon to WG's wiki page:
<https://community.icann.org/display/gTLDRDS/Glossary+of+RDS+Terms> Glossary
of RDS Terms
Possible WG Agreement: DN Management is a legitimate purpose for collecting
some registration data, based on the definition supplied by DT2 (and/or the
extended definition above).
· Note: WG may still split this apart into two separate purposes
during further deliberation on data.
Action: Staff to develop a poll on the above possible WG agreement; all WG
members encouraged to participate in the poll no later than COB Saturday 9
December.
c. Time permitting, deliberate on data needed for that purpose
· Review data identified by DT2 as necessary for this purpose (slide
12)
· Question: Did DT2 consider data not already included in existing
WHOIS data elements that might be needed for this purpose?
· DT2 considered if something new was needed - notably, role-based
contacts - but did not give data beyond existing WHOIS data a lot of
thought.
· Deliberation on data collected for the purpose of DN Management to
continue in next WG call
4. Confirm action items and proposed decision points
WG Agreement: The following information is to be collected for the purpose
of Technical Issue Resolution associated with Domain Name Resolution:
· Technical Contact(s) or (if no Technical Contact is provided)
Registrant Contact(s),
· Nameservers,
· Domain Status,
· Expiry Date and Time,
· Sponsoring Registrar.
Action: Staff to record polled statement as rough consensus WG Agreement in
working document, including footnote noting that a possible need for Tech
Contact AND Registrant Contact (rather than Tech Contact OR Registrant
Contact) will be further deliberated later, as data element agreements are
refined.
Possible WG Agreement: DN Management is a legitimate purpose for collecting
some registration data, based on the definition supplied by DT2 (and/or the
extended definition).
Action: Staff to develop a poll on the above possible WG agreement; all WG
members encouraged to participate in the poll no later than COB Saturday 9
December.
5. Confirm next WG meeting: Tuesday, 12 December at 17:00 UTC
Meeting Materials (all posted at https://community.icann.org/x/MAByB)
· Including Call Handout:
<https://community.icann.org/download/attachments/74580016/Handout-5Dec-RDSW
GCall.pdf?version=1&modificationDate=1512416898000&api=v2>
Handout-5Dec-RDSWGCall.pdf (includes poll results and DT2 definition)
·
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20171205/017cf369/attachment-0001.html>
More information about the gnso-rds-pdp-wg
mailing list