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

[Sarah Tarrant <[e-mail]>]

Hi Eliot,

There are no further items left for either of you, and we are moving this document forward in the publication process at this time.

Thank you for your attention and guidance during the AUTH48 process.

Sincerely,
RFC Editor/st

> On Jan 9, 2024, at 9:23 AM, Independent Submissions Editor (Eliot Lear) <[e-mail]> wrote:
> 
> Thanks, Sarah.  Is there anything left for either Joachim or me on this?
> 
> On 09.01.2024 15:53, Sarah Tarrant wrote:
>> Hi Joachim,
>> 
>> a) Regarding the display with Opera/Chrome:
>> We have reported the issue, and our tools team is working on it. Thank you for providing the stats for them.
>> 
>> b) Regarding:
>>> I think it will be necessary that the document reference should be updated at IANA to the upcoming RFC 9517. This applies to the information regarding the key 'ddi' in the urn.arpa zone and to the list of registered URN namespaces. I'm not clear who can initiate this process.
>> 
>> IANA will automatically do this once the RFC is published. Feel free to reference https://www.rfc-editor.org/faq/#iana for information about this IANA process.
>> 
>> Thank you,
>> RFC Editor/st
>> 
>>> On Jan 8, 2024, at 2:08 PM, Joachim Wackerow <[e-mail]> wrote:
>>> 
>>> Hi Sarah, hi Eliot,
>>> 
>>> Sarah:
>>> 
>>> Thank you very much for the clear communication in this process and your edit work.
>>> 
>>> Regarding the rendering issue:
>>> The screenshots I sent show the rendering of the Opera version 79.0.4195.76330 and the Chrome version 120.0.6099.145. Both with Android 12 SM-T865.
>>> 
>>> Firefox version 120.1.0 with the same Android shows the expected output.
>>> 
>>> Sarah and Eliot:
>>> 
>>> Regarding IANA:
>>> I think it will be necessary that the document reference should be updated at IANA to the upcoming RFC 9517. This applies to the information regarding the key 'ddi' in the urn.arpa zone and to the list of registered URN namespaces. I'm not clear who can initiate this process.
>>> 
>>> Kind regards
>>> Joachim
>>> 
>>> 
>>> 
>>> 
>>> 
>>> -------- Original message --------
>>> From: Sarah Tarrant <[e-mail]>
>>> Date: 1/8/24 18:25 (GMT+01:00)
>>> To: Joachim Wackerow <[e-mail]>, "Independent Submissions Editor (Eliot Lear)" <[e-mail]>
>>> Cc: RFC Editor <[e-mail]>, [e-mail]
>>> Subject: Re: [AD] AUTH48: RFC-to-be 9517 for your review
>>> 
>>> Hi Joachim and Eliot,
>>> 
>>> Joachim - For our tools team can assess the viewing issue on your side, we would need to know your:
>>>    •
>>> OS version info
>>>    • browser version info
>>>    • CSS modifications/plugins (if any)
>>> 
>>> 
>>> When we view the html (using macOS version 14.1.1, Mozilla Firefox version 121.0), this is the output we get:
>>> 
>>> <utf-8''Screenshot%202024%2D01%2D08%20at%2011.09.43%E2%80%AFAM.png>
>>> All - As this is the output we were expecting and we have received all necessary approvals, we do consider AUTH48 complete:
>>> https://www.rfc-editor.org/auth48/rfc9517
>>> 
>>> Thank you for your attention and guidance during the AUTH48 process.
>>> 
>>> We will move this document forward in the publication process at this time.
>>> 
>>> Sincerely,
>>> RFC Editor/st
>>> 
>>>> On Jan 5, 2024, at 9:02 AM, Joachim Wackerow <[e-mail]> wrote:
>>>> 
>>>> Hi Sarah, hi Eliot,
>>>> 
>>>> Thank you for the final changes. All looks good.
>>>> 
>>>> Regarding:
>>>>> I noticed some unusual rendering of the list of services in the section 4.4 in the HTML version. Is this intended?
>>>> I think the current solution is fine. The XML makes sense to me. All versions (PDF, TXT) look good but the HTML rendering in the browsers Chrome and Opera look a little weird because of the small font for the definition text, see attached screen shots (Firefox is fine). I used the browsers currently with Android. The CSS might be not robust across browsers?
>>>> 
>>>> Thanks again for all your efforts.
>>>> Joachim
>>>> 
>>>> 
>>>> 
>>>> -------- Original message --------
>>>> From: "Independent Submissions Editor (Eliot Lear)" <[e-mail]>
>>>> Date: 1/2/24 17:53 (GMT+01:00)
>>>> To: Sarah Tarrant <[e-mail]>
>>>> Cc: Joachim Wackerow <[e-mail]>, RFC Editor <[e-mail]>, [e-mail]
>>>> Subject: Re: [AD] AUTH48: RFC-to-be 9517 for your review
>>>> 
>>>> Right you are, thank you. Assuming Joachim is okay with this, I approve.
>>>> 
>>>> On 02.01.2024 17:50, Sarah Tarrant wrote:
>>>>> Hi Eliot,
>>>>> 
>>>>> We updated per your request but took out the second “not” to avoid the double negative.
>>>>> 
>>>>> Requested:
>>>>> This Independent Submission is not a standard nor does it not have IETF community consensus.
>>>>> 
>>>>> Current:
>>>>> This Independent Submission is not a standard nor does it have IETF community consensus.
>>>>> 
>>>>> The updated 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 Jan 2, 2024, at 10:14 AM, Independent Submissions Editor (Eliot Lear) <[e-mail]> wrote:
>>>>>> 
>>>>>> 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
>>>>>> 
>>>>>> 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
>>>>>>>>> 
>>>> <Screenshot_20240105-155736_Opera.jpg><Screenshot_20240105-155709_Chrome.jpg>