[NCAP-Discuss] Current Status of the NCAP Project

Mon Nov 14 20:53:51 UTC 2022

(1) v6 support is a red herring. Knock it off. Everyone. This is a distraction.

(2) I hear you Anne – I’m writing a highly proceduralized version of what happened in 2012 as that seems to be where we’re all talking past one and other. Expect midweek.

Thx,
Jeff

From: NCAP-Discuss <ncap-discuss-bounces at icann.org> on behalf of Aikman-Scalese, Anne <AAikman at lewisroca.com>
Date: Monday, November 14, 2022 at 2:57 PM
To: rubensk at nic.br <rubensk at nic.br>, James Galvin <galvin at elistx.com>
Cc: NCAP Discussion Group <ncap-discuss at icann.org>
Subject: Re: [NCAP-Discuss] Current Status of the NCAP Project

Rubens,

The written system for a Name Collision Assessment Framework is supposed to be in place for all future rounds and as you know, future rounds are supposed to be ongoing based on the policy adopted in the Sub Pro Final Report.   It's not at all about IPv6 TODAY.

I’ll add that anyone who wants to see .MAIL move forward (as you have advocated many times) won't be happy with a fallback to the 2012 Framework which bans it.  In addition, I don't know how many times I have to say this, but we need a Framework that assesses risk at the point of application and that was not in place in 2012.  Implementation Guidance from Sub Pro says we also need for the risk assessment to occur in the “evaluation process” as well as “during the transition to delegation”.  So there are two phases of risk assessment described there.  To my non-technical mind, this comports with PCA and ACA.  I leave the assessment of the efficacy of those risk assessment systems to the technical folks and the SSAC.  Casey’s report does a lot to clarify that certain risks of a new system are “unknown”.  I will point out, however, that I agree with Heather that no aspect of “Public Reception” is technical in nature.   That category does not belong in Casey’s chart.

All these offhand references on the list to "non-technical" people and what we "need to understand" are obscuring the need for clarity.  We need a written Name Collision Assessment Framework in place that can be adopted by the Board.  And the Community At Large and the GAC need to be able to understand it along with all the rest of us non-technical people.  Will you and Jeff please get your proposed language and charts in place rather than just taking "pot shots" at the current draft?  Please be sure to include your proposals for the “DNS Stability Evaluation”  and the “name collision risk criteria and a test” as set forth in the Sub Pro Implementation Guidance.

Recommendation 29.1: ICANN must have ready prior to the opening of the Application
Submission Period a mechanism to evaluate the risk of name collisions in the New gTLD
evaluation process as well as during the transition to delegation phase

Implementation Guidance 29.4: To the extent possible, all applied-for strings
should be subject to a DNS Stability evaluation to determine whether they
represent a name collision risk.

Implementation Guidance 29.5: The ICANN community should develop name
collision risk criteria and a test to provide information to an applicant for any
given string after the application window closes so that the applicant can
determine if they should move forward with evaluation.

Thank you,

Anne

Anne E. Aikman-Scalese

Of Counsel

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

D. 520.629.4428

Lewis Roca Rothgerber Christie LLP

One South Church Avenue, Suite 2000

Tucson, Arizona 85701-1611

lewisroca.com

-----Original Message-----
From: NCAP-Discuss <ncap-discuss-bounces at icann.org<mailto:ncap-discuss-bounces at icann.org>> On Behalf Of Rubens Kuhl via NCAP-Discuss
Sent: Monday, November 14, 2022 12:19 PM
To: James Galvin <galvin at elistx.com<mailto:galvin at elistx.com>>
Cc: NCAP Discussion Group <ncap-discuss at icann.org<mailto:ncap-discuss at icann.org>>
Subject: Re: [NCAP-Discuss] Current Status of the NCAP Project

Jim.

It doesn't matter if the share of IPv6-preferred hosts grow and even reach near 100%. The issue, or lack thereof, is with IPv6-only hosts. This ratio is abysmally low which is why adding IPv6 brings zero benefit.

You may not remember, but the organization I work for is also an address resource registry (an NIR). We keep track of the development in IPv6 deployment both number-wise and device-wise, and try fostering the growth of IPv6 whenever we can. But we are both not seeing IPv6-only hosts and not advocating for IPv6-only hosts. They could exist in the distant future, and I hope my kids will live long enough to see them, possibly at the end of this century.

Rubens

> On 14 Nov 2022, at 15:48, James Galvin <galvin at elistx.com<mailto:galvin at elistx.com>> wrote:

>

> I agree with your observation that controlled interruption fails for IPv6-only hosts.  I’m not yet ready to concede that dual-stacked or XLAT networks are not similarly impacted as we haven’t looked at that scenario.

>

> As far as adding IPv6 support to collision assessment being a zero-sum game, I disagree with that.  As I noted below, IPv6 usage may be small and increasing at a very low rate however, as a technical point, this does not justify dismissing collision assessments on an IPv6 network.

>

> At a minimum, the DG was tasked to consider how to assess collisions in the future.  Since IPv6 is present today and is increasing, however slowly, I think the DG would be remiss if it did not consider whether or not there was a solution for when IPv6 was in use.  Since we have found a solution the DG would be negligent if it did not call it out, on its technical merits.

>

> Jim

>

>

> On 13 Nov 2022, at 19:20, rubensk at nic.br<mailto:rubensk at nic.br> wrote:

>

>>> On 12 Nov 2022, at 22:53, James Galvin <galvin at elistx.com<mailto:galvin at elistx.com>> wrote:

>>>

>>> A few comments inline.

>>>

>>> On 11 Nov 2022, at 10:52, Casey Deccio wrote:

>>>

>>>>> \On Nov 10, 2022, at 4:34 AM, James Galvin <galvin at elistx.com<mailto:galvin at elistx.com>> wrote:

>>>>>

>>>>> I consider the following things better.

>>>>>

>>>>> 1. Frankly, [lack of IPv6 support] was a serious technical gap in the 2012 Controlled Interruption

>>>>

>>>> It is a fact that controlled interruption does not support IPv6.  While I do agree that IPv6 support is *desirable*, I am interested to know why you feel that this is a "serious technical gap".  And to be clear, I'm not talking about the general advancement of IPv6; I'm talking about the goals of controlled interruption.  I have taken time to write categories for technical consideration in the comparison doc, among which are the goals for alerting and data collection.  Also in that doc are descriptions of how controlled interruption and the other proposed techniques measure up.

>>>

>>> A goal of controlled interruption is to work on today’s Internet.  Today’s Internet includes IPv6.  Failing to cover IPv6 increases the risk that controlled interruption will not achieve the goal of manifesting name collisions.  And while the traffic volume of IPv6 may be increasing ever so slowly, whatever that rate is becomes the same rate at which the risk of controlled interruption failing to achieve its goal will also increase.

>>>

>>> Thus, on this one key point, both PCA and ACA are vastly superior to controlled interruption.

>>

>> Today's Internet is composed of IPv4-only hosts and IPv4 and IPv6 capable hosts (either thru dual-stacked networks or IPv6 + 464 XLAT networks). Controlled interruption only fails in IPv6-only hosts, for which there are almost none whatsoever. So this alleged improvement is 0 at this point and in the foreseeable future.

>>

>>

>> Rubens

________________________________

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/20221114/a60a5bc6/attachment-0001.html>