[NCAP-Discuss] Report Changes Based on Public Comments

Fri Apr 5 22:35:58 UTC 2024

Without additional input, I will have to defer to my best judgment
regarding incorporating Jim’s and Anne’s points as the final documents need
to be finalized by 5p PT.

On Fri, Apr 5, 2024 at 4:09 PM Michael Monarrez Puckett <
monarrez4565 at gmail.com> wrote:

> All,
>
> Per Jim’s first point, the sentence is “There must be a process for
> removing strings test delegated to the root zone from the root after their
> addition to the Collision String List [based on TRT review].” As Jim
> pointed out, this statement was included somewhere it didn’t necessarily
> need to be included.
>
> 5.9.1 (ICANN should support a mechanism that allows applicants to request
> a string be removed from the Collision String List) includes this statement
> primarily. Other uses of this statement refer back to this section.
>
> As for the second point, Jim is correct in pointing out that the statement
> “The TRT should not have the operating authority to request the emergency
> removal of one of the strings…They should, however, be part of the process
> to assess the request…”
>
> An earlier section provides more context that is required here, which
> states that “The TRT should not have the operational authority to effect
> the emergency removal…If the TRT identifies an issue with a delegation,
> they must contact the IANA function to handle the issue within accepted
> emergency processes.”
>
> This takes into account Anne’s suggestion to change my initial use of
> “enact” to “effect.”
>
> On Fri, Apr 5, 2024 at 3:47 PM James Galvin <galvin at elistx.com> wrote:
>
>> Thank you to Michael for his yeoman’s work getting us to here. I have
>> given this document yet one more read and I am pleased to be able to
>> support it being published.
>>
>> However, I do have two issues with the final text that I call out here.
>> Perhaps our Chairs, if not Michael, could respond and help me to understand
>> what I’m missing.
>>
>> 1. I deleted a sentence that I believe simply does not belong. I inserted
>> bookmark at the sentence so folks can jump right there and see it:
>> https://drive.google.com/drive/u/0/folders/1ailLZ63CG_p71FTQzc8ANJhnRgqR7H10
>> .
>>
>> In fact, if you scroll from there you’ll see I deleted the same sentence
>> from multiple recommendations, in part because they are out of context and
>> also because they are not quite accurate. Once you get to Recommendation
>> 5.9.1, you’ll see I added a comment that suggests that perhaps rather than
>> deleting this sentence everywhere it can be rewritten to suggest that folks
>> look forward to Rec 5.9.1. for details on managing the Collision String
>> List.
>>
>> 2. Unless I’ve completely missed some discussion we had, I think the last
>> paragraph in Recommendation 10 in Section 5.10 is backwards. Here’s a
>> bookmark that takes you precisely to the paragraph:
>> https://docs.google.com/document/d/1TO8uQf_17DwITy-jQUvPfDR9dcIk7nX_KLjjKQ0akcg/edit#bookmark=id.i7g1134p7tcy
>> .
>>
>> You’ll see in my comment that what I believe happened is two separate
>> responsibilities got conflated inappropriately. Specifically, it seems to
>> me that the TRT expressly has the responsibility and the accountability to
>> make sure that an emergency removal from the root zone happens if needed.
>> It might make this decision itself or might be called upon to assess a
>> request if it’s an external report. What the TRT does not have is the
>> operational authority or responsibility to actual remove the string from
>> the root zone. That is something that only IANA can do.
>>
>> I do not remember any discussion different than that. Can somebody point
>> me at when this got flipped, or is this just an editorial oversight?
>>
>> Thanks,
>>
>> Jim
>>
>>
>> On 3 Apr 2024, at 3:39, Michael Monarrez Puckett wrote:
>>
>> Hello all,
>>
>> Below are a summary of the changes made to the report based on
>> last week's discussion of adopted changes based on public comments. Most of
>> the changes are to make statements less direct using passive voice (rather
>> than stating that the TRT should or that ICANN org must). These were the
>> only items outstanding from changes to the report related to public
>> comments. I will be amending the public comments Annex to account for
>> adopted changes and to prepare that document for the final package.
>>
>> - Removed references to research about IPv6-only hosts being out of
>> scope; Replaced with "IPv6 is a risk tradeoff which was thoroughly
>> discussed in the JAS report. There is no clear, risk-free approach to
>> 2012-style CI in v6 space." in Sec. 3.5.2 on CI
>> - Specified that regarding the process for emergency changes to the root
>> zone when considering the temporary delegation of strings, there is no
>> "publicly documented" process in Finding 4.7
>> - Removed references to ICANN org needing to provide sufficient resources
>> for implementation quick like a bunny; Made statement more passive/general:
>> "sufficient resources would be required for expeditious implementation."
>> - Removed all references to future studies being necessary as the DNS
>> evolves.
>> - Removed references to TRT having responsibility for removing strings
>> test-delegated to the root from the root upon their addition to the
>> Collision String List; Made statement more passive/general by stating that
>> there must be a process for doing so.
>> - Removed reference to the TRT recommending time frames for the Name
>> Collision Risk Assessment Framework; Made statement more passive/general:
>> "time frames...should be distributed to the public as early as possible"
>>
>> Over the next three days, I will focus on non-material editing and
>> additional necessary preparations to finalize all documents for delivery by
>> this Friday, April 5. Should I find inconsistencies that require technical
>> expertise, I will be sure to reach out to this group for guidance.
>> Otherwise, I'm pleased to share that we are on track for delivery by the
>> expected date.
>>
>> Thanks,
>> Michael Monarrez Puckett
>>
>> On Thu, Mar 21, 2024 at 2:41 PM Michael Monarrez Puckett <
>> monarrez4565 at gmail.com> wrote:
>>
>>> Hello all!
>>>
>>> tl;dr -- Action items:
>>> - Review Annex: Public Comments Analysis
>>> <https://docs.google.com/document/d/1QXc6giTfSRsfLtvxJjzrHzFT1aCPuJgALFVPWZUbVtw/edit>
>>> - Review edits to draft report
>>> <https://docs.google.com/document/d/1TO8uQf_17DwITy-jQUvPfDR9dcIk7nX_KLjjKQ0akcg/edit>
>>> based on public comments
>>> - See organized Final Report folder
>>> <https://drive.google.com/drive/u/0/folders/1ailLZ63CG_p71FTQzc8ANJhnRgqR7H10>
>>> in shared drive
>>>
>>> Thank you Matt Larson and Matt Thomas for your feedback on the public
>>> comments Annex document. I've made updates to the responses to public
>>> comments and the agreed-upon adoptions of edits to the report. Please see
>>> the Annex and add comments with feedback as you see fit as this document
>>> will be part of the final report package and contain responses on behalf of
>>> the NCAP DG to each public comment.
>>>
>>> I've updated the report with the edits based on public comments. These
>>> edits I've made in Suggesting mode. Please take the time between now and
>>> next week's meeting to review changes to the report, add comments, or make
>>> changes in Suggesting mode. Note that the changes are only in relation to
>>> the DG's responses to public comments.
>>>
>>> I've created a folder in the shared drive titled "0 Final Draft," which
>>> contains the edited draft report, the draft Board Questions document, and
>>> the annex of public comments analysis. This folder is intended to organize
>>> the documents that will be part of the final parcel delivered to SSAC:
>>> https://drive.google.com/drive/u/0/folders/1ailLZ63CG_p71FTQzc8ANJhnRgqR7H10
>>>
>>>
>>> If you have any questions, comments, concerns, or suggestions, please
>>> take the time over the next week to make your voice heard so that we can
>>> wrap up the Final Report in due time.
>>>
>>> Thank you,
>>> Michael
>>>
>>> On Thu, Mar 21, 2024 at 5:01 AM Thomas, Matthew <mthomas at verisign.com>
>>> wrote:
>>>
>>>> Michael,
>>>>
>>>>
>>>>
>>>> Thank you for putting this together.  I just reviewed and placed a few
>>>> comments/suggest in the document.  Overall, I think this is in good shape;
>>>> however ……
>>>>
>>>>
>>>>
>>>> @ALL-NCAP-DG – Please, please, please take some time to review and
>>>> comment/suggest!  We are so close to the finish line.  Let’s get this done!
>>>>
>>>>
>>>>
>>>> Matt Thomas
>>>>
>>>>
>>>>
>>>> *From:* NCAP-Discuss <ncap-discuss-bounces at icann.org> on behalf of
>>>> Michael Monarrez Puckett <monarrez4565 at gmail.com>
>>>> *Date:* Tuesday, 19 March 2024 at 01:27
>>>> *To:* "ncap-discuss at icann.org" <ncap-discuss at icann.org>
>>>> *Subject:* [EXTERNAL] [NCAP-Discuss] Report Changes Based on Public
>>>> Comments
>>>>
>>>>
>>>>
>>>> *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.
>>>>
>>>> Hello team!
>>>>
>>>>
>>>>
>>>> Here’s a link to the completed Annex of public comments received, NCAP
>>>> DG responses, and report changes adopted.
>>>>
>>>>
>>>>
>>>> Please review the responses in column 4 (NCAP DG Response) and leave a
>>>> comment in the document should you have any concerns or suggestions.
>>>>
>>>>
>>>> https://docs.google.com/document/d/1QXc6giTfSRsfLtvxJjzrHzFT1aCPuJgALFVPWZUbVtw/edit
>>>>
>>>>
>>>>
>>>> I’m currently in the process of editing the report based upon the DG’s
>>>> responses to public comments. I will share those edits with the group as
>>>> soon as possible—by tomorrow or Wednesday at the very latest.
>>>>
>>>>
>>>>
>>>> Having the report edits reviewed and approved (or else modified based
>>>> on feedback) prior to next week’s meeting would be ideal.
>>>>
>>>>
>>>>
>>>> Thanks!
>>>>
>>>> Michael
>>>>
>>>> ———
>>>>
>>>>
>>>>
>>>> Focal points for report edits:
>>>>
>>>> - Operationalization of TRT and implementation of Name Collision Risk
>>>> Assessment Framework should be expeditious, for which ICANN org would need
>>>> to provide sufficient resources.
>>>>
>>>> - TRT should have the responsibility to remove a string from the String
>>>> Collision List upon finding that the risk of collision has been
>>>> appropriately mitigated.
>>>>
>>>> - All strings should be subject to a typical technical evaluation
>>>> process without preferential review treatment for any grouping of strings.
>>>> The implementation of special procedures for certain types of strings based
>>>> upon policy adoption is out of scope for this report.
>>>>
>>>> - Further research by the ICANN community will be necessary based on
>>>> evolutions in the DNS and name resolution issues.
>>>>
>>>> - The data collection methods proposed for the TRT are a small sampling
>>>> of known and tested methods. Other methods may be used, but they remain
>>>> untested and are out of scope within this report. Ultimately, which methods
>>>> to use should be critically considered during the operationalization of the
>>>> TRT.
>>>>
>>>> - The NCAP DG deliberated on the proposed data collection methods as a
>>>> sample of possible and available methods based upon careful consideration
>>>> and balance of data privacy risks and potential benefits.
>>>>
>>>> - Data that is presently available to the public, which applicants
>>>> could use to self-assess their applications is constrained.
>>>>
>>>> - The data to be made publicly available to applicants should be
>>>> recommended by the TRT during its implementation based upon critical focus
>>>> of data sources that would strengthen applications.
>>>>
>>>> - The TRT should distribute time frames to the public as early as
>>>> possible for stages of the Name Collision Risk Assessment Framework based
>>>> on implementation details.
>>>>
>>>> - Updated the agreed-upon definition of “name collision” within the
>>>> report based on the response from ICANN org.
>>>>
>>>> - The NCAP DG does not find it within its remit to provide specific
>>>> guidance on elements of the operationalization of the Technical Review Team
>>>> and the Name Collision Risk Assessment Framework, including what data to
>>>> collect, how to assess this data, and how to maintain compliance with data
>>>> privacy and risk management standards. The intent of not prescribing
>>>> implementation details is for ICANN org to have broadly lateral oversight.
>>>>
>>>> - The ICANN org would need to implement a data privacy and protection
>>>> policy, along with appropriate risk mitigation measures for legal
>>>> compliance.
>>>>
>>> _______________________________________________
>>
>> 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/20240405/4d994a4e/attachment-0001.html>