[NCAP-Discuss] "Do Not Apply"

Wed Sep 13 20:56:06 UTC 2023

In the spirit of keep name collision assessment as a modular point in 
time in the overall process, I would say we have two choices about how 
to deal with your concern.

On the one hand, I don’t think we need to solve that problem as it 
should be part of the overall process elsewhere.  So, say nothing.

On the other hand, for completeness, we should say that these issues may 
be a concern and that we are not addressing this concern.  What we 
should say is that all other requirements or guidance applies and that 
this process is just a name collision assessment and not intended to 
supersede any other concerns, in particular guidance that might be in 
place regarding root scaling.

Jim

On 12 Sep 2023, at 13:23, Jeff Schmidt via NCAP-Discuss wrote:

> I did not realize that Study 2 was split into 2 separate documents. In 
> the second doc, I see:
>
>> Finding B.c: It is impractical to create a do-not-apply list of 
>> strings in advance of new requests for delegation
>
> Which directly answers my question below.
>
>
> --
> However, I also noticed:
>
>> 5.5 Recommendation 5 - ICANN must support the delegation of strings 
>> in order to improve the ability to conduct a name collision risk 
>> assessment
>
> Noting this is a "must" and we have not addressed the IANA/root size 
> issue (at all) is a problem.
>
> This would also put us in direct conflict with SubPro:
>
> Recommendation 26.2: ICANN must honor and review the principle of 
> conservatism when adding new gTLDs to the root zone.
>
> Recommendation 26.3: ICANN must focus on the rate of change for the 
> root zone over smaller periods of time (e.g., monthly) rather than the 
> total number of delegated strings for a given calendar year.
>
> Implementation Guidance 26.4: The number of TLDs delegated in the root 
> zone should not increase by more than approximately 5 percent per 
> month, with the understanding that there may be minor variations from 
> time-to-time.
>
>
> Jeff
>
>
> From: NCAP-Discuss <ncap-discuss-bounces at icann.org> On Behalf Of Jeff 
> Schmidt via NCAP-Discuss
> Sent: Thursday, September 7, 2023 10:42 AM
> To: Rubens Kuhl <rubensk at nic.br>; ncap-discuss at icann.org
> Subject: Re: [NCAP-Discuss] "Do Not Apply"
>
> Agree. But since it's Guidance ICANN needs to either follow it or 
> explain why not. NCAP can't be slient.
>
> From: NCAP-Discuss 
> <ncap-discuss-bounces at icann.org<mailto:ncap-discuss-bounces at icann.org>> 
> on behalf of Rubens Kuhl via NCAP-Discuss 
> <ncap-discuss at icann.org<mailto:ncap-discuss at icann.org>>
> Date: Thursday, September 7, 2023 at 10:12 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: Re: [NCAP-Discuss] "Do Not Apply"
>
> Jeff,
>
> In SubPro lingo, an Implementation Guidance is akin to a SHOULD in BCP 
> 14. So lack of an NCAP position on it won't make ICANN Org to have to 
> do it... it's not a MUST.
>
> That said, there would be no harm in having that specified by NCAP.
>
>
>
> Rubens
>
>
>
>
> Em 7 de set. de 2023, à(s) 11:52, Jeff Schmidt via NCAP-Discuss 
> <ncap-discuss at icann.org<mailto:ncap-discuss at icann.org>> escreveu:
>
> Team:
>
> SubPro said:
>
> Implementation Guidance 29.3: To the extent possible, ICANN should 
> seek to identify high-risk strings in advance of opening the 
> Application Submission Period, which should constitute a "Do Not 
> Apply" list. ICANN should also seek to identify aggravated risk 
> strings in advance of the next application window opening and whether 
> it would require a specific name collision mitigation framework.
>
> We (NCAP) have talked quite a bit about the difficulties of an 
> a-priori collisions "Do Not Apply" list. I "think" we are all in 
> agreement that such a list cannot be produced, however such 
> assumptions are dangerous. I looked in Study 1 and the draft of Study 
> 2 and they are both, surprisingly, silent on the NCAP position on "Do 
> Not Apply."
>
> Is there consensus that NCAP will state that a-priori "Do Not Apply" 
> is not possible? If so, this should be included in Study 2. If not, 
> uhm, add it to the discussion list.
>
> Thanks!
> Jeff
>
>
> _______________________________________________
> NCAP-Discuss mailing list
> NCAP-Discuss at icann.org<mailto: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.

> _______________________________________________
> 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/20230913/c1132882/attachment-0001.html>