[NCAP-Discuss] 24 April Meeting Materials

Tue Apr 30 21:15:45 UTC 2019

I would like to apologize to the group for not making the meeting - I don't
have a great excuse; I was awaiting a large delivery, and the truck arrived
just as the meeting was about to start.

Sorry,
W

On Tue, Apr 30, 2019 at 4:08 PM Steve Sheng <steve.sheng at icann.org> wrote:

> Dear NCAP Discussion Group,
>
>
>
>   Attached please find:
>
>    - The notes and action items from the 24 April meeting
>    - Jay’s presentation on the overview of the project including
>    definition of name collisions
>    - The latest full project proposal
>
>
>
>   Please also find the study 1 proposal in google doc format. As Jim
> mentioned on the call, DG members are encouraged to provide feedback on 1)
> the study goals, 2) anything that needs to be clarified, and 3) gaps in
> deliverables and tasks.
>
>
>
>
> https://docs.google.com/document/d/15f1Kh2vuY0yF9SelocGrPOguYPXDeFYZ0lTqx3fU_gI/edit?usp=sharing
>
>
>
>   Please review this document ahead of tomorrow’s call and provide your
> input.
>
>
>
> Best
>
> Steve
>
>
>
>
>
> On 4/24/19, 6:49 PM, "NCAP-Discuss on behalf of Rubens Kuhl" <
> ncap-discuss-bounces at icann.org on behalf of rubensk at nic.br> wrote:
>
>
>
>
>
>     I'll do a bit of copy-paste here to the comfort of NCAP WP
> participants, but first I need to stress that since this is an initial
> report, it doesn't reflect any consensus, and it also don't carry minority
> views that could be totally opposed for what's in it.
>
>
>
>     Identified issues:
>
>
>
>     ● APD lists included a number of desirable terms and trademarks to be
> only available after the launch cycle of the TLD, interacting badly with
> launch programs, marketing initiatives and RPMs.
>
>     ● The after-the-fact nature of establishing the framework severely
> impacted time-to-market of approved TLDs.
>
>     ● Late start of controlled interruption added to more delays.
>
>     ● The Work Track has not reached an agreement on TLDs with a higher
> than usual risk level (.home, .corp and .mail).
>
>     ● Some TLDs contradicted the framework by having both wildcard
> controlled interruption and delegated domain names.
>
>     ● Risks were overplayed by some actors and downplayed by others,
> making it harder for the ICANN organization to choose an accepted risk
> level.
>
>     ● Some side effects of controlled interruption for specific SLDs
> required disabling controlled interruption for the whole TLD.
>
>
>
>     Overall tone
>
>
>
>     ● Expanding 2012 Framework with categorization of low, aggravated,
> and high risk, on elaborating “do not apply” and “exercise care” lists;
>
>     ● Keeping readiness requirement for life-threatening collisions; and
>
>     ● For low-risk strings, on starting controlled interruption as soon
> as possible and delegate execution to ICANN.
>
>
>
>
>
>     Recommendations:
>
>
>
>     2.7.8.c.1: Include a mechanism to evaluate the risk of name collisions
> in the TLD evaluation process as well during the transition to delegation
> phase.
>
>
>
>     2.7.8.c.3: Efforts should be undertaken to create a “Do Not Apply”
> list of TLD strings that pose a substantial name collision risk whereby
> application for such strings would not be allowed to be submitted.
>
>
>
>     2.7.8.c.4: In addition, a second list of TLDs should be created (if
> possible) of strings that may not pose as high of a name collision risk as
> the “Do Not Apply” list, but for which there would be a strong presumption
> that a specific mitigation framework would be required.
>
>
>
>     2.7.8.c.5: Allow every application, other than those on the “do not
> apply” list, to file a name collision mitigation framework with their
> application.
>
>
>
>     2.7.8.c.6: During the evaluation period, a test should be developed to
> evaluate the name collision risk for every applied-for string, putting them
> into 3 baskets: high risk, aggravated risk, and low risk. Provide clear
> guidance to applicants in advance for what constitutes high risk,
> aggravated risk, and low risk.
>
>
>
>     2.7.8.c.7: High risk strings would not be allowed to proceed and would
> be eligible for some form of a refund.
>
>
>
>     2.7.8.c.8: Aggravated risk strings would require a non-standard
> mitigation framework to move forward in the process; the proposed framework
> would be evaluated by an RSTEP panel.
>
>
>
>     2.7.8.c.9: Low risk strings would start controlled interruption as
> soon as such finding is reached, recommended to be done by ICANN org for a
> minimum period of 90 days (but likely more considering the typical timeline
> for evaluation, contracting and delegation).
>
>
>
>     2.7.8.c.10: If controlled interruption (CI) for a specific label is
> found to cause disruption, ICANN org could decide to disable CI for that
> label while the disruption is fixed, provided that the minimum CI period
> still applied to that string.
>
>
>
>     ======
>
>
>
>     There were also some questions that tried to get more community input
> on specific topics. The comments received from the community can be seen at
>
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_spreadsheets_d_133WbhWYB4M4kT6DqSfiCR2-2Dij7jxNkLj5EWZL-2DNA95M_edit-23gid-3D1737964707&d=DwIGaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=O16Ko7V_SvDE5jZHxFQsUEzduEwmIp0AxPl2Gzy-KTc&m=Bs5FzZTLCjEHwvQhyFJ0-3JWKPvSBjxZ7mh1tSerd04&s=1nsT0_nt779MREg1PbdNHORxa1wqMZ5IZxhkoD8JqIU&e=
>
>     (sheet 2.7.8 Name Collisions)
>
>
>
>     The WG has yet to go thru the recommendations and comments to produce
> a final report, which may come this calendar year.
>
>
>
>     From the WG discussions and comments, I noticed that there are those
> that believe the 3-tier classification (High/Aggravated/Low Risk) might not
> be achievable, and also some doubt where a "Do Not Apply" list could be
> made or not. Whether this will cause merging of High and Aggravated but
> allowing a mitigation framework to be filed even for the High Risk strings,
> subject to the string plus mitigation being approved or denied, and
> changing the "Do Not Apply" list to "Apply at your own risk", is yet to be
> seen.
>
>
>
>     There are also those not comfortable with other themes, but I don't
> see a direct link to the NCAP WP work. But the content is all there so
> anyone can take their own judgement on that.
>
>
>
>
>
>     Rubens
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>     _______________________________________________
>
>     NCAP-Discuss mailing list
>
>     NCAP-Discuss at icann.org
>
>     https://mm.icann.org/mailman/listinfo/ncap-discuss
>
>
> _______________________________________________
> NCAP-Discuss mailing list
> NCAP-Discuss at icann.org
> https://mm.icann.org/mailman/listinfo/ncap-discuss
>

-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/ncap-discuss/attachments/20190430/7e2ac253/attachment.html>