[dns-operations] ICANN Name collision framework

[Rubens Kuhl]

(Sorry if you have received more than 1 copy of this e-mail, since this is being sent to technical mailing lists focusing on DNS)

There is ongoing policy development effort within ICANN towards subsequent procedures of new gTLDs releases; during the last round in 2012, one of the last pieces of the program to be defined was the name collision framework, detailed at https://www.icann.org/resources/pages/name-collision-2013-12-06-en <https://www.icann.org/resources/pages/name-collision-2013-12-06-en> .

The current thinking is to keep most of the framework as it was in that round, with minor changes for low risk strings and some more detail for other strings. The base principle is to use research-accessible trusted databases such as DITL and ORDINAL to make decisions.

In chronological order, the process would be like this:

1) Pre-application procedure
ICANN Org would provide a "do not apply" list containing strings like localhost and an "exercise care" list containing strings such as the ones hitting root servers with large number of invalid queries, where it's expected that a non-standard mitigation framework would be required.

2) Application time
Applicants would need to file a mitigation framework for "exercise care" strings but could file one for other strings as well.

3) Evaluation time
Each applied-for unique string would be evaluated and divided into 3 buckets of strings: high-risk strings would have their applications terminated, aggravated risk ones would require non-standard mitigation framework and low-risk strings would use the standard framework. Note that "exercise care" strings might turn out to be low-risk, or strings not listed in any list might turn out to be high or aggravated risk.

4) Controlled interruption
As soon as a decision is made regarding risk assessment, ICANN Org itself would perform 90 days or more of wildcard 127.0.53.53 controlled interruption for all low-risk strings. This would be different from the 2012-round as this was done by registry operators after they got IANA delegation. IANA delegation of those will be actually a redelegation to registry operators.
ICANN Org would have the option to decide answer NXDOMAIN instead of 127.0.53.53 for specific labels that caused disruption, with the understanding that those labels would still require 90 days of controlled interruption to be later used.

5) Aggravated risk strings
Each framework will be evaluated using registry services technical evaluation procedures and carried out by registry operator, with ICANN monitoring its compliance.

Some of the questions still to be answered by the WG include:
- Guidelines, lists and/or procedures for creating "do no apply" and "exercise care" lists
- Guidelines and/or procedures for applied strings risk assessment
- Whether 2-year readiness for collisions with potential harm to human life should still exist since none was detected in the 2012-round, and only 37 collisions were reported to ICANN.
- Whether 2012-round TLDs that already completed their 2-year readiness cycles should still have some kind of operational readiness thru the lifecycle of the TLD.


So, the reasons for outreaching to this technical group include:
- Whether someone has feedback for the current thinking of the process. Nothing is final until they are final.
- Whether someone has feedback on the unanswered questions so progress can be made in those areas.


Thanks!
Rubens Kühl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20170819/32da8bec/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20170819/32da8bec/attachment.sig>