[NCAP-Discuss] Reminder - Board Questions

Tue Jan 3 21:36:22 UTC 2023

Matt,
I have some smaller comments below but I wanted to raise a couple of “big picture” comments first:

  1.  Although we state in the Conclusion section that name collisions are a risk management problem, it is not actually clear in other sections where we are answering questions that we have a handle on criteria to be measured for making the risk assessment in a proactive manner.  We make some general references to “high volume and/or high diversity of queries and query names” as well as  “high metrics”   on page 12 but we don’t say what we mean by those terms.  It’s important to note that not everyone on the Board possesses a technical understanding of “high volume”, “high diversity” or “high metrics”.  I think we have to explain or give examples  of what these terms mean and we have to say that we are developing the metrics in Study 2 in connection with a proposal for measuring name collision risk pro-actively.

  1.  There are no concrete references to the new Name Collision Assessment Framework that the DG is working on until the Conclusion paragraph and it is not even mentioned by name in that paragraph.  I think the Board will find this very confusing since one of the direct questions is “(4) possible courses of action that might mitigate harm “.  This questions is summarized on page 10 as “What possible courses of action can ICANN org take that might mitigate harm?   In the section on Proactive Measures, we should say that the DG is working to finalize a Recommendation for public comment that proposes a new Name Collision Assessment Framework.

  1.  In the Summary and Conclusion, I think we need to add that controlled interruption measures from the 2012 round did not address any IPv6 issues (and any other issues that have arisen since 2012.)  For example I heard Jeff Schmidt say recently that there are problems using Day In the Life (DITL) data?  This is discussed a bit on page 16-17 but I think it has to be stated more simply in the Conclusion section.

If we don’t address the above communication issues more directly, I think that what arrives in the Board’s inbox will be viewed as “theoretical exploration” of topics with no value to the Board in terms of being able to translate the answers into any sort of decision-making framework.  Personally, I don’t feel competent to add to the drafting since the responses are highly technical in nature.  How can we incorporate the above suggestions into the responses and at that same time, greatly SIMPLIFY the information the Board needs to digest?

More detailed comments/questions:

p.4 – In the middle of the page, we refer to “formal denotation” of name collisions”.  Do we mean “formal definition”?  If so, can we say so?

p. 5 – last paragraph – Could we please be more clear with explaining how the “private use of DNS suffixes” affects the name collision risk assessment?

p.6 – at the top – “uninstantiated” names – what does this mean?  Is there a simpler way to describe them?  Is this an object-oriented computing term?

p. 6 – last sentence of first paragraph.  “Those reactions ultimately depend on whatever signal is used internally to indicate a name does not exist”.   With respect to what is happening at the end user level, does “whatever signal” mean a notification to the end user?  And what do we mean by “internally”?  Internal to what?  Are we saying,  “In other words, the impact of negative answers depends on the notification mechanism to the end user?”

p. 6 – Last paragraph.  We have draft sentences which say as follows:  “Search list design that used second, third, and lower labels in a domain name (such as CORP, HOME, and MAIL) that would never appear in the root and would be easily resolved with search list processing because of negative responses.  This assumption is no longer valid.”  There seems to be a structural issue with the first sentence.  Can you please clarify?  Is there an extra “that” at the beginning of this sentence?

p. 8 – With respect to the section on Communication Interception, is it worth mentioning the effect of DNS SEC in connection with this risk?

p. 9 – second paragraph – I would suggest adding “Two historical sources of data from the 2012 round….” to clarify the nature of the data you are describing.

p. 10 –11 – The Board question is “What possible courses of action can ICANN org take that might mitigate harm?”   As noted above, in the section on “Proactive Measures to Reduce the Potential for Harm”, I have the following comments:
 (a) Top of page 12 – last sentence of that paragraph – I don’t understand the analogy made comparing “controlled interruption” to a vaccination.  I also think that such an analogy is essentially way too loaded at this time in world health history.  If we are saying that controlled interruption gives a “snapshot” of risk at a certain period of time and may catch early end users of the name which is subject to the collision risk, then can we just say that?  In what way does this operate as a “vaccine” if the notification disappears?
(b) The third paragraph makes the references to “high volume”, “high diversity” and “high metrics”  I don’t think Board members have any context for what we mean by this and it’s surprising we make no reference to the work the NCAP DG is doing to define  these criteria for the purpose of creating a new Name Collision Assessment Framework that the Board will be able to ultimately use in the next round of new gTLDs.
(c) page 13 j- middle of page “In some cases, proactive investigation of name collisions might yield a set of TLD strings whose query characteristics  are significantly high , enough so that outreach to identify the root cause and encourage configuration change might prove to be infeasible – at least in the short term.  In such cases, it might be more prudent to maintain a collision string registry of potentially problematic strings….”.     Again, no reference whatsoever to the work the DG is doing to develop criteria to assess such strings.  All the “might” and “could” language is not helpful here.

p. 14 – Risks of Delegation

In the first bullet point, we state that “We are limited to the data we have available to make assessments with regard to name collisions”.  This implies that all the data exists at this point in time and doesn’t take into account the system that the NCAP DG is developing in order to assess data when a new string is applied for.  I think it’s important to keep in mind that the Board is looking for ways to apply risk management to the next round.   In the third bullet point, I had to look up “heuristic” to see it means “speculative formulation”.  Then at the end of that section we essentially say that all we can say about risk is that it is “non-zero”.  To my mind, this entire section is not at all helpful to the Board’s decision-making process.

p.  17 – Summary – Here we are talking about summarizing the answers related to “Criteria for Determining Whether a Collision String Should Not Be Delegated”, “Criteria for  Removal of a Collision String from the Do-Not-Delegate List” and “Data Requirements for String Determination” as well as “Concerns about Data Manipulation”.  The Summary should definitely refer to the metrics being developed in connection with Study 2 and should identify the fact that the NCAP DG has been working on a refined Name Collision Assessment Framework for years.  We should also say that in its present form, the proposal includes a “Technical Review Team” as opposed to making a vague reference to “technical experts”.  It will be the job of the Technical Review Team to assess both quantitative and qualitative risk and provide that risk assessment to the Board but the Summary gives no indication whatsoever that this proposed structure is being designed or “in the works” or going out for public comment anytime soon.  ( It just isn’t really helpful for our responses to be so theoretical.)

p/ 18 – next to the last paragraph – “each scenario must be handled on a case-by-case basis”.  If we are talking about analyzing risk in relation to each proposed new string, we definitely need to say so rather than talking about a “scenario”.    This paragraph is the first time we mention offering guidance to the Board on name collision risk management.  In this regard, I would recommend that the Conclusion section appear at the beginning of these responses to the Board questions and be labelled Executive Summary.   The responses would then end with the Summary section and I think the whole document would have a better reception at the Board level.

Thank you,
Anne

Anne E. Aikman-Scalese

Of Counsel

AAikman at lewisroca.com<mailto:AAikman at lewisroca.com>

D. 520.629.4428

[cid:image002.png at 01D91F75.FACE2970]

From: NCAP-Discuss <ncap-discuss-bounces at icann.org> On Behalf Of Thomas, Matthew via NCAP-Discuss
Sent: Tuesday, January 3, 2023 7:13 AM
To: ncap-discuss at icann.org
Subject: Re: [NCAP-Discuss] Reminder - Board Questions

[EXTERNAL]
________________________________
This time with the attachments.

From: NCAP-Discuss <ncap-discuss-bounces at icann.org<mailto:ncap-discuss-bounces at icann.org>> on behalf of "Thomas, Matthew via NCAP-Discuss" <ncap-discuss at icann.org<mailto:ncap-discuss at icann.org>>
Reply-To: "Thomas, Matthew" <mthomas at verisign.com<mailto:mthomas at verisign.com>>
Date: Tuesday, January 3, 2023 at 7:56 AM
To: "ncap-discuss at icann.org<mailto:ncap-discuss at icann.org>" <ncap-discuss at icann.org<mailto:ncap-discuss at icann.org>>
Subject: [EXTERNAL] [NCAP-Discuss] Reminder - Board Questions

Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

NCAP DG,

Happy New Year! This is a gentle reminder for you to review the draft Board Question document.

Please take some time to review the document and comment (directly in the Google doc if possible) with any questions or suggested changes.  The NCAP DG will be discussing and reviewing this document *tomorrow* during the NCAP DG call and we are still targeting a consensus call by mid-January.

The link to the Board Questions (PDF/Word copies attached for convenience):

https://docs.google.com/document/d/17C342jQVjtx98NxWM7GBZAjVktY-Ipgl63u7mWURq18/edit#<https://docs.google.com/document/d/17C342jQVjtx98NxWM7GBZAjVktY-Ipgl63u7mWURq18/edit>

Best,

Matt Thomas
NCAP co-chair

________________________________

This message and any attachments are intended only for the use of the individual or entity to which they are addressed. If the reader of this message or an attachment is not the intended recipient or the employee or agent responsible for delivering the message or attachment to the intended recipient you are hereby notified that any dissemination, distribution or copying of this message or any attachment is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the sender. The information transmitted in this message and any attachments may be privileged, is intended only for the personal and confidential use of the intended recipients, and is covered by the Electronic Communications Privacy Act, 18 U.S.C. §2510-2521.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/ncap-discuss/attachments/20230103/ec052c74/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 224 bytes
Desc: image001.png
URL: <https://mm.icann.org/pipermail/ncap-discuss/attachments/20230103/ec052c74/image001-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 2031 bytes
Desc: image002.png
URL: <https://mm.icann.org/pipermail/ncap-discuss/attachments/20230103/ec052c74/image002-0001.png>