[NCAP-Discuss] "Do Not Apply"

[Jeff Schmidt]

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/ncap-discuss/attachments/20230912/31032ef4/attachment.html>