[gnso-rds-pdp-wg] IMPORTANT: Notes from RDS PDP WG Meeting - 21 November

Tue Nov 21 19:26:11 UTC 2017

Dear all,

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

To recap Action Items from today's call:

Proposed WG Agreement: Technical Issue Resolution is a legitimate purpose
for AT MINIMUM resolving issues with domain name resolution.

Action Item: Test above WG agreement with a poll. All WG members are
encouraged to respond to poll by COB Saturday 25 November.

Best regards,
Lisa

Action Items and Notes from RDS PDP WG Call - 21 November 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/LAByB

1. Roll Call/SOI Updates

.        No SOI updates

2. Building block plan for answering "Purpose" charter question

.        Call handout:
<https://community.icann.org/download/attachments/74580012/Handout-21Nov-RDS
WGCall-v3.pdf>
https://community.icann.org/download/attachments/74580012/Handout-21Nov-RDSW
GCall-v3.pdf

3. Deliberate on Technical Issue Resolution as a legitimate purpose for
collecting, maintaining, and providing access to registration data

.        Starting from definition developed by DT1:

.        Information collected to enable contact of the relevant contacts to
facilitate tracing, identification and resolution of incidents related to
services associated with the domain name  by persons who are affected by
such issues, or persons tasked (directly or indirectly) with the resolution
of such issues on their behalf.

.        One use case given as example - facilitating contact with someone
who can help resolves technical or operational issue with DNS

.        "Who" is who are trying to contact, not the person initiating the
contact

.        Question: Is there a use case where the RDS data can be used to
resolve the issue without contacting someone?

.        Answer: There may be additional use cases that involve
investigation alone, such as spotting a DNS name server address mismatch

.        Another example: You get (e.g.) a mail bounce because the name
doesn't exist, and you look in WHOIS and see the domain is on Hold, then you
know that there's no actual technical problem to solve (the name shouldn't
resolve)

.        Question: Did DT consider having the registrar retain the data
needed for Tech Issue Resolution to enable subsequent resolution rather than
having the RDS provide a data query service?

.        Answer: Contact needed may not be registrar but another Technical
contact, there may be other ways of providing data but the DT focused on
defining the purpose and data needed for that purpose

.        Question: Should the purpose focus on issues with the DNS or issues
with services associated with the domain name? For example, if a website is
hacked, is it ICANN's responsibility to provide a contact for that website?

.        Difference of opinion on how far to go into "operational issues" 

.        For example, the DNS provides top level name allocation and
resolution of domain names via caching. The ability to look up parties
responsible for top level domain names (tech contacts for DN, and registrar)
is a critical piece of running a distributed system like the Internet.
Inherently a distributed system - I need to be able to reach the person
operating the network corresponding to a gTLD domain name.

.        From chat: This is why the current "Revised ICANN Procedure For
Handling WHOIS Conflicts with Privacy Law" constantly references "Keeping in
the mind the anticipated impact on the operational stability, reliability,
security, or global interoperability of the Internet's unique identifier
systems" when discussing changes to WHOIS

.        Should additional use cases be developed - should additional
purpose(s) be identified other than a narrowly-focused DNS technical issue
resolution purpose?

.        Back in the early days of the DNS, many would keep lists of
contacts/IP addresses because DNS didn't always work - we don't want to go
back to those situations where technical issue resolution was very difficult

.        Data minimization also doesn't = less data, but no more data than
necessary to fulfill the purpose.

.        From chat: ICANN is responsible for SSR or the Internet, the
responsibility for the Internet is distributed to many different
organizations and individuals, these things all interoperate to make the
Internet actually "work", technical issues in one space can affect others,
someone needs to be contacted in order to solve many of these issues to keep
the Internet working, ICANN is charged with managing the distribution of
these resources, thus it comes back to ICANN to ensure that issues can be
resolved via contacts associated with the domains it manages the
distribution of, thus RDS.

.        Question: Can DT1 elaborate on Server Status and how it is needed
for Technical Issue Resolution?

.        Answer: For example, hold status may explain why a name isn't
resolving, status may explain why a domain name cannot be transferred -
helps you understand what can and cannot be done with the domain name at
this time, useful for registrant, registry, and often third parties

.        Question: Wouldn't abuse responder/reporter fall under the Criminal
Activity/DNS Abuse purposes instead of this one?

.        Technical issue resolution may involve informing a party involved
with the issue, or it may involve trying to resolve the issue (technical
issues not other issues)

.        What is within ICANN's remit? For example, if email bounces, it
could be due to many reasons, including a domain name not resolving. If the
DN is not resolve, it's a DNS issue that needs investigation/resolving.
Another example, browsing to a website and the page doesn't come up. If the
reason given is that the domain doesn't exist, then it's a DNS issue and I
want to look up information about that domain name. But it may go beyond
ICANN

.        Proposed clarification to definition: Make a distinction between
issues with domain name resolution for services associated with the TLD and
issues with the services themselves

.        Are contact details all needed to resolve all technical issues, or
would a ROID or an email address be sufficient?

.        Note that EWG recommended new kinds of optional contacts which
would not be required but could be provided to help resolve various kinds of
issues.

.        From chat: if you don't want to be subject to contact, don't
register to operate public-facing infrastructure,, because registering a TLD
is offering to operate infrastructure at that domain name

.        If not in ICANN's remit, then whose remit is it? If the whole
Internet requires tech issue resolution in an inherently distributed system,
and ICANN policy doesn't provide data needed for that, then who should be
responsible for it?

.        Do all other issues fall under this, because they may have
technical resolutions? No. But for example would DNS abuse fall under this
as an additional tech issue 

.        Test using show of hands:

.        Do you agree that tech issue resolution is a legit purpose for AT
MINIMUM resolving issues with DN resolution?

.        No red Xs, only green checks in AC

.        Second test using show of hands:

.        Do you agree that tech issue resolution is a legit purpose for
resolving additional issues?

.        Several red Xs in addition to green checks in AC

.        Rationale: This is too broad; saying additional or related issues
is not sufficiently specific

.        Third test using show of hands:

.        Do you agree that tech issue resolution is a legit purpose for
resolving additional issues that are directly dependent on DN resolution?

.        Somewhat more support but still several Xs

.        May need to provide some examples to illustrate scope of
"additional issues"

Proposed WG Agreement: Technical Issue Resolution is a legitimate purpose
for AT MINIMUM resolving issues with domain name resolution.

4. Confirm action items and proposed decision points

Proposed WG Agreement: Technical Issue Resolution is a legitimate purpose
for AT MINIMUM resolving issues with domain name resolution.

Action Item: Test above WG agreement with a poll. All WG members are
encouraged to respond to poll by COB Saturday

5. Confirm next WG meeting: Wednesday, 29 November at 06:00 UTC

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

.        Meeting Handout:
<https://community.icann.org/download/attachments/74580012/Handout-21Nov-RDS
WGCall-v3.pdf?version=1&modificationDate=1511268087000&api=v2>
Handout-21Nov-RDSWGCall-v3.pdf (includes Tech Issue Resolution definition,
updated 21 Nov)

.
<https://community.icann.org/download/attachments/74580012/DT1%20-%20TechIss
ues-Research-final.pdf?version=1&modificationDate=1511134384000&api=v2> DT1
- TechIssues-Research-final.pdf and
<https://community.icann.org/download/attachments/74580012/DT1%20-%20TechIss
ues-Research-final.docx?version=1&modificationDate=1511134399000&api=v2> DOC

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