[NCAP-Discuss] Current Status of the NCAP Project

[Tom Barrett]

Ditto.  What Anne Said.

Tom


On Mon, Nov 14, 2022, 2:57 PM Aikman-Scalese, Anne <AAikman at lewisroca.com>
wrote:

> 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
>
> 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> On Behalf Of Rubens
> Kuhl via NCAP-Discuss
> Sent: Monday, November 14, 2022 12:19 PM
> To: 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
>
>
>
>
>
> 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> 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 wrote:
>
> >
>
> >>> On 12 Nov 2022, at 22:53, James Galvin <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>
> 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.
> _______________________________________________
> NCAP-Discuss mailing list
> NCAP-Discuss at icann.org
> https://mm.icann.org/mailman/listinfo/ncap-discuss
>
> _______________________________________________
> By submitting your personal data, you consent to the processing of your
> personal data for purposes of subscribing to this mailing list accordance
> with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and
> the website Terms of Service (https://www.icann.org/privacy/tos). You can
> visit the Mailman link above to change your membership status or
> configuration, including unsubscribing, setting digest-style delivery or
> disabling delivery altogether (e.g., for a vacation), and so on.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/ncap-discuss/attachments/20221114/b367a320/attachment-0001.html>