2017-11-21 Next Gen RDS PDP Working Group

Notes/ Action Items

 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 Updates

• No SOI updates

2. Building block plan for answering “Purpose” charter question

• Call handout: https://community.icann.org/download/attachments/74580012/Handout-21Nov-RDSWGCall-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