[NCAP-Discuss] Enhanced Controlled Interruption and Predictability

[Thomas, Matthew]

All,

It feels that this discussion has started to muddle name collisions directly with harm and completely remove the intermediary and critical component of _risk.  The Board questions were constructed to provide them with a better understanding of the _risk of a delegating a string based on name collision telemetry. Based on data, they can make a quantitative judgement as to their risk appetite of delegating a string. I don’t think anyone on the DG is saying that all name collisions queries are potentially harmful; however, it is well established that various classes of name collision queries seen via the DNS present documented threat vectors that can be weaponized and can be potentially harmful.  That being said – the other collision queries may or may not pose _risk.

"I don’t think it is accurate to say that mitigation may impose more costs on all parties than the harm" (which would have been presented as _risk before delegation) caused in the first place is an accurate statement.  We’ve seen in the NCAP DG calls how numerous collision strings were remediated by basic CDM analysis and basic outreach efforts. To your point of making a predictable path forward for the Board – I think we are all in alignment with that objective; however, we need to be very careful not to conflate risk and harm.  These are two very different concepts that the Board will want to understand, and we need to convey clearly.

Matt





On 2/24/22, 4:46 PM, "NCAP-Discuss on behalf of Jeff Neuman" <ncap-discuss-bounces at icann.org on behalf of jeff at jjnsolutions.com> wrote:

    Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. 

    Agreed 100%.  The motivation behind the collision is absolutely relevant to the decision of whether caution needs to be taken.  If you are taking advantage of a loophole for your own economic advantage, then that is very relevant.

    I also want to remind everyone that throughout this entire process we have been taking the view where we are assuming that if there is a collision there is harm.  I never agreed with that approach and I still do not.  But we proceeded with the work on the  basis that we wanted more information about the collisions and why they occurred regardless of whether any "harm" was inflicted.

    But now, in answering the Board's question, they specifically asked us about identifying harm and essentially weighing the factors of whether the "harm caused by the collision" outweighed the benefits of the delegation.  

    That always must be used.  We cant just say that if there is a collision there is a harm that must be mitigated.  That makes no sense.  The mitigation may impose more costs on all parties than the harm caused in the first place.

    And Anne - I am not sure where you are going with your argument.  The point is that groups within ICANN need to stick to their swim lanes.  The SSAC addresses Security and Stability issues and provides ADVICE to the Board.  The GNSO is responsible for developing policies with respect to gTLDs.  The question of how to handle collisions represent both policy and technical issues.  If there is a conflict between the "technical solution" and the "Policies", then there must be an attempt to come up with something that works from all sides.  It cannot be that the SSAC recommends a technical solution and policies be damned.

    At the end of the day the Board will need to make a decision as to whether a predictable process outweighs the potential harm by name collisions and find a way forward.

    Finally, we cannot just tell applicants that you have to "guess" as to what an acceptable mitigation plan might look like, spend lots of money on experts to figure out what actually needs to be mitigated, and only then to find out that ICANN has no way of deeming whether that plan is acceptable or not. That I fear is the path we are heading down and that goes against all of the principles unanimously approved by the GNSO that Subsequent Rounds must follow a predictable process.


    Jeffrey J. Neuman
    Founder & CEO
    JJN Solutions, LLC
    p: +1.202.549.5079
    E: jeff at jjnsolutions.com
    http://jjnsolutions.com


    -----Original Message-----
    From: NCAP-Discuss <ncap-discuss-bounces at icann.org> On Behalf Of Rubens Kuhl via NCAP-Discuss
    Sent: Thursday, February 24, 2022 12:16 PM
    To: ncap-discuss at icann.org
    Subject: Re: [NCAP-Discuss] Enhanced Controlled Interruption and Predictability



    > On 24 Feb 2022, at 12:46, Tom Barrett via NCAP-Discuss <ncap-discuss at icann.org> wrote:
    > 
    > 
    > The Board's overarching goal should be to prevent or minimize consumer harm in approving new delegations.
    > 
    > I don't think it is relevant whether potential collisions are accidental or deliberate.  In either case, whether the potential collisions become actual collisions is entirely under ICANN's control and the Board will still want to be able to understand the consumer harm that would be caused with a new delegation.
    > 
    > This simply may not align with giving predictability to new gtld applicants.
    > 
    > Since assessing consumer harm is beyond the remit of the NCAP's current study, I suspect that they will return to SSAC and ask for another study.

    Minimizing harm is a worthy goal, but whether potential collisions are accidental or deliberate needs to be taken into account. Otherwise, ICANN is opening a loophole that anyone wanting a string just needs to cause enough collisions so that string is not delegated in the DNS, while the same perpetrator uses it at a competing namespace.

    We don't tell people to not drive on the streets because of DUI drivers; we arrest and prosecute such drivers, allowing law-abiding citizens to drive as safely as possible.


    Rubens

    _______________________________________________
    NCAP-Discuss mailing list
    NCAP-Discuss at icann.org
    https://secure-web.cisco.com/1hutRkq0Hp8LpRAQCnMOZRWVjYcFEUWek6AIfQoSnDdYwQhhLb61crONPGEIOIxKL2E68UyzRJTejdsHriDmC4lXyZtDgEPLklUj34oGAlVzxzl3Pv0gX1RmrUKti7gRReAAAWQb1hB9DTCbjFH6U__ovH6X6sdg-qpixZohck82TKX-uZ5Rn4LdWJsa8lu7n-bKLzoto4-nRAbh7DNciSd1qHrjRcaj2vplBBTkNBzGpvI7Ye745lo1-MKOnaSuO/https%3A%2F%2Fmm.icann.org%2Fmailman%2Flistinfo%2Fncap-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://secure-web.cisco.com/1rTwOlVyFpWjFhvFsyfF-8-jefvgx8VNOQS8oA8pvv6ErWdwXrg179fzuNUsRvlLMeNm4kwlCVTTxIBZOt0zB7td2Qkdc2rIhpwexEvXHWj9Tu4qJ8mxC4bAQSv5jgwVLtWWMJnG8MVxp1IMsaQbfpXC0k5pwC1wDpPVN8XOyVb3Uo6pG4HMF43AUxqn6VtFzXPpeGHbGhgwqxek2Gwt6jfc0FkGMSksRSSJYdiRIgfp_guvLvpIUAwoys9d4f3wd/https%3A%2F%2Fwww.icann.org%2Fprivacy%2Fpolicy) and the website Terms of Service (https://secure-web.cisco.com/1JDIUF5GeoKOKklN3hW7CK48bW0zawLjdMKk_9-fJqy82vgMOcWDBnwlEO4hinZoytxp2Z_pwVPOFMtq7OdF70VIsGSKSHwR2sxs_2dFQUSqXk_-1eZ43vI4KKQixIDUMz2GBVL-gZQBdxVE9VQjydrTtAqFO6WOp3ASmx6xTGB1O5k38yMPLiXYMDXLCCmidnh4szTVBYH0-n0Pg88VBRYqIMKjHXOiapUw5y7F2msRI_bDlxuX-wN_yCJB-pMEQ/https%3A%2F%2Fwww.icann.org%2Fprivacy%2Ftos 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.