Re: [auth48] [AD] Re: AUTH48: RFC-to-be 9517 <draft-urn-ddi-06> for your review

["Independent Submissions Editor (Eliot Lear)" <[e-mail]>]

Hi Sarah and Joachim

My apologies.  I note one change needed in the abstract.

OLD:

The DDI Alliance is not affiliated with the Internet Engineering Task 
Force (IETF) or Internet Society (ISOC), and this Independent Submission 
does not have IETF community consensus.

NEW:

The DDI Alliance is not affiliated with the Internet Engineering Task 
Force (IETF) or Internet Society (ISOC).  This Independent Submission is 
not a standard nor does it not have IETF community consensus.

--

Eliot



    <https://www.rfc-editor.org/authors/rfc9517.html#name-status-of-this-memo>

On 02.01.2024 16:08, Sarah Tarrant wrote:
> Hi Joachim and Eliot,
>
> Thank you for your replies. We have updated the document accordingly, and noted Joachim's approval on the AUTH48 status page for this document (http://www.rfc-editor.org/auth48/rfc9517).
>
> Eliot - We await your AD approval prior to moving forward in the publication process.
>
> Joachim - Regarding:
>> I noticed some unusual rendering of the list of services in the section 4.4 in the HTML version. Is this intended?
> The output appears to be correct to us, as this is an unordered list inset with definition list items, which is why the space between the colon (:) and “given” is longer than other spaces. Would you prefer the terms and their definitions be formatted as an inset unordered list? This would remove the larger space and add an asterisk in front of each term.
>
> Current:
>     * DDI repository
>          I2R (URI to Resource):    given a DDI URN return, one instance of
>          the resource identified by that URN.
>
>     * DDI registry
>          I2C (URI to URC, Uniform Resource Characteristics are
>          descriptions of resources):    given a DDI URN return, a description
>          or a summary of that resource.
>
>     * DDI URN resolution
>          I2L (URI to URL):    given a DDI URN return, one URL that identifies
>          a location where the identified DDI resource can be found.
>
>          I2Ls (URI to URLs):    given a DDI URN return, one or more URLs that
>          identify multiple locations of the identified DDI resource.
>
> Perhaps:
>     * DDI repository
>          * I2R (URI to Resource): given a DDI URN return, one instance of
>          the resource identified by that URN.
>
>     * DDI registry
>          * I2C (URI to URC, Uniform Resource Characteristics are
>          descriptions of resources): given a DDI URN return, a description
>          or a summary of that resource.
>
>     * DDI URN resolution
>          * I2L (URI to URL): given a DDI URN return, one URL that identifies
>          a location where the identified DDI resource can be found.
>
>          * I2Ls (URI to URLs): given a DDI URN return, one or more URLs that
>          identify multiple locations of the identified DDI resource.
>   
>
> The files have been posted here (please refresh):
>   https://www.rfc-editor.org/authors/rfc9517.txt
>   https://www.rfc-editor.org/authors/rfc9517.pdf
>   https://www.rfc-editor.org/authors/rfc9517.html
>   https://www.rfc-editor.org/authors/rfc9517.xml
>
> The relevant diff files have been posted here (please refresh):
>   https://www.rfc-editor.org/authors/rfc9517-diff.html  (comprehensive diff)
>   https://www.rfc-editor.org/authors/rfc9517-auth48diff.html  (AUTH48 changes only)
>
> Thank you,
> RFC Editor/st
>
>> On Dec 23, 2023, at 9:43 AM, Joachim Wackerow<[e-mail]>  wrote:
>>
>> Hello Sarah,
>>
>> Thank you for the updated text. All looks good.
>>
>> The changes in Section 6 are fine.
>>
>> Please correct a typo in 3.2. Relevant Ancillary Documentation
>>
>> OLD: "Lexcal grammar"
>>
>> NEW: "Lexical grammar"
>>
>> For answers to the questions, see below in the text.
>>
>> I noticed some unusual rendering of the list of services in the section 4.4 in the HTML version. Is this intended?
>>
>> Thanks again for your thourough editorial work.
>>
>> Kind regards
>> Joachim
>>
>> -------- Original message --------
>> From: Sarah Tarrant<[e-mail]>  
>> Date: 12/22/23 15:42 (GMT+01:00)
>> To: "Independent Submissions Editor (Eliot Lear)"<[e-mail]>, Joachim Wackerow<[e-mail]>  
>> Cc: RFC Editor<[e-mail]>,[e-mail]  
>> Subject: Re: AUTH48: RFC-to-be 9517 for your review
>>
>> Hello Joachim and Eliot*,
>>
>> Eliot* - Please review the updated text and added artwork element to the IANA Considerations in Section 6:
>>
>> Old:
>>     The registration for "ddi" in the "URN.ARPA" zone is approved.
>>     Requests for the domain ddi.urn.arpa will be delegated to the name
>>     servers of the DDI Alliance.
>>
>> New:
>>     The following NAPTR record for the key "ddi" has been registered in
>>     the urn.arpa zone:
>>
>>        ddi IN NAPTR 100 10 "" "" "" registry.ddialliance.org
>>
>>     Requests for the domain ddi.urn.arpa are delegated to the name
>>     servers of the DDI Alliance.
>>
>>
>> Joachim - thank you for your reply. We have updated the document accordingly.
>>
>> 1) We await your response to the inclusive language question about “man-in-the-middle" and Eliot’s suggested update:
>>
>>> NIST recommends one of the following alternatives:
>>> machine-in-the-middle attack; on-path attack
>>> Are either acceptable to you?
>> JW: machine-in-the-middle attack is fine
>>
>> 2) Please note that for the updated IANA text above we updated “will be delegated” to “are delegated” to match the other updates in the document (e.g., “will promote” to “promotes”). Please let us know if there are any objections.
>>
>> JW: this is fine.
>>
>> 3) Please review the document carefully to ensure satisfaction as we do not make changes once it has been published as an RFC. Contact us with any further updates or with your approval of the document in its current form. We will await approvals from each author prior to moving forward in the publication process.
>>
>> JW: I approve this document for publication assuming that the two changes mentioned above will be made.
>>
>> The files have been posted here (please refresh):
>>    https://www.rfc-editor.org/authors/rfc9517.txt
>>    https://www.rfc-editor.org/authors/rfc9517.pdf
>>    https://www.rfc-editor.org/authors/rfc9517.html
>>    https://www.rfc-editor.org/authors/rfc9517.xml
>>
>> The relevant diff files have been posted here (please refresh):
>>    https://www.rfc-editor.org/authors/rfc9517-diff.html  (comprehensive diff)
>>    https://www.rfc-editor.org/authors/rfc9517-auth48diff.html  (AUTH48 changes only)
>>
>> For the AUTH48 status of this document, please see:
>> https://www.rfc-editor.org/auth48/rfc9517
>>
>> Thank you,
>> RFC Editor/st
>>
>>> On Dec 22, 2023, at 8:34 AM, Independent Submissions Editor (Eliot Lear)<[e-mail]>  wrote:
>>>
>>> Hi Joachim
>>> Thanks for your answers.  On the following:
>>> On 17.12.2023 11:10, Joachim Wackerow wrote:
>>>> 19) <!-- [rfced] Please review the "Inclusive Language" portion of the
>>>>> online Style Guide<https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
>>>>> and let us know if any changes are needed.
>>>>>
>>>>> For example, please consider whether the following should be updated:
>>>>> man-in-the-middle
>>>>> -->
>>>>> JW: The term seems to be established, see:https://en.wikipedia.org/wiki/Man-in-the-middle_attack. I'm not aware of any inclusive version.
>>>>>
>>>>>
>>> NIST recommends one of the following alternatives:
>>> machine-in-the-middle attack; on-path attack
>>> Are either acceptable to you?
>>> Eliot