Re: [auth48] [AD] AUTH48: RFC-to-be 9472 <draft-ietf-opsawg-sbom-access-18> for your review

[Eliot Lear <[e-mail]>]

Ok, I’ve reviewed this.  I think in this instance, since we are talking about a JSON example, and the JSON document ignores spaces and still parses, we can just leave it as is.  I don’t think it’s necessary to reflow.  Are you okay with that Rob?

Eliot

> On Sep 27, 2023, at 12:32, Rob Wilton (rwilton) <[e-mail]> wrote:
> 
> Hi Sarah, Eliot,
> 
> Sorry for the delay.
> 
> Regarding the changes in 5.1 and 5.3:
> 
> Rather than outdenting, did we consider leveraging RFC 8792?  E.g., to cite a random specific example, see the end of section 2.2.2 of https://datatracker.ietf.org/doc/draft-ietf-netconf-crypto-types/
> 
> Example:
>   =============== NOTE: '\' line wrapping per RFC 8792 ================
> 
>   <rpc-reply message-id="101"
>     xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
>     <p10-csr xmlns="http://example.com/ns/example-crypto-types-usage">\
>   BASE64VALUE=</p10-csr>
>   </rpc-reply>
> 
> The advantage of this is that tooling can extract the example from the RFC and still give a completely normal properly indented example.  I'm not sure how many recent YANG RFCs have started to do this, but I think that this is what I'm starting to more commonly see.
> 
> Thanks,
> Rob
> 
> 
>> -----Original Message-----
>> From: Sarah Tarrant <[e-mail]>
>> Sent: Friday, September 22, 2023 3:15 PM
>> To: Eliot Lear <[e-mail]>
>> Cc: Rob Wilton (rwilton) <[e-mail]>; Rose, Scott W. (Fed)
>> <[e-mail]>; RFC Editor <[e-mail]>; opsawg-
>> [e-mail]; [e-mail]; [e-mail];
>> [e-mail]
>> Subject: Re: [AD] AUTH48: RFC-to-be 9472 <draft-ietf-opsawg-sbom-access-18>
>> for your review
>> 
>> Hi Eliot,
>> 
>> Thank you for your reply. We have marked your approval on the AUTH48 status
>> page for this document (see https://www.rfc-editor.org/auth48/rfc9472).
>> 
>> IANA has completed the update to the “YANG Module Names” registry.
>> 
>> We will move this document forward in the publication process once we receive
>> approval from Rob on the changes to the sourcecode in Sections 5.1 and 5.3.
>> 
>> Thank you,
>> RFC Editor/st
>> 
>>> On Sep 21, 2023, at 1:32 AM, Eliot Lear <[e-mail]> wrote:
>>> 
>>> Hi Sarah,
>>> 
>>> I approve publication.  Thanks to you and the RPC for your work on this
>> document.
>>> 
>>> Eliot
>>> 
>>>> On 20 Sep 2023, at 22:59, Sarah Tarrant <[e-mail]> wrote:
>>>> 
>>>> Hi Eliot,
>>>> 
>>>> Thank you for spotting the issue with Section 7.2 and the IANA registry. We
>> agree that "ietf-mud” should be updated to "ietf-mud-transparency” in Section
>> 7.2 and have made that change. In a separate email, we will request that IANA
>> update the “YANG Module Names” registry accordingly.
>>>> 
>>>> Updated XML file:
>>>> http://www.rfc-editor.org/authors/rfc9472.xml
>>>> 
>>>> Updated output files:
>>>> https://www.rfc-editor.org/authors/rfc9472.html
>>>> https://www.rfc-editor.org/authors/rfc9472.txt
>>>> https://www.rfc-editor.org/authors/rfc9472.pdf
>>>> 
>>>> Diff file showing all changes made during AUTH48:
>>>> https://www.rfc-editor.org/authors/rfc9472-auth48diff.html
>>>> 
>>>> Diff files showing all changes:
>>>> https://www.rfc-editor.org/authors/rfc9472-diff.html
>>>> https://www.rfc-editor.org/authors/rfc9472-rfcdiff.html (side-by-side diff)
>>>> 
>>>> Note that it may be necessary for you to refresh your browser to view the
>> most recent version.
>>>> 
>>>> For the AUTH48 status of this document, please see:
>>>> https://www.rfc-editor.org/auth48/rfc9472
>>>> 
>>>> Thank you,
>>>> RFC Editor/st
>>>> 
>>>>> On Sep 19, 2023, at 12:42 AM, Eliot Lear <[e-mail]> wrote:
>>>>> 
>>>>> Hi Sarah,
>>>>> 
>>>>> I think I’ve caught one more small issue, but this is with the IANA registry.
>> Could you please check with them on the following:
>>>>> 
>>>>> In 7.2, I think the name field is supposed to be ietf-mud-transparency and
>> not ietf-mud.
>>>>> 
>>>>> After this matter is resolved, I can approve publication.
>>>>> 
>>>>> Thanks,
>>>>> 
>>>>> Eliot
>>>>> 
>>>>> 
>>>>>> On 18 Sep 2023, at 20:37, Sarah Tarrant <[e-mail]> wrote:
>>>>>> 
>>>>>> Hello Eliot and Rob*,
>>>>>> 
>>>>>> Elliot, thank you for your reply. We have updated the document
>> accordingly.
>>>>>> 
>>>>>> *Rob, as AD, please review and approve the changes to the sourcecode in
>> Sections 5.1 and 5.3. These changes are best viewed in this diff file:
>> https://www.rfc-editor.org/authors/rfc9472-auth48diff.html.
>>>>>> 
>>>>>> We will await approvals from each of the parties listed above prior to
>> moving this document forward in the publication process.
>>>>>> 
>>>>>> Updated XML file:
>>>>>> http://www.rfc-editor.org/authors/rfc9472.xml
>>>>>> 
>>>>>> Updated output files:
>>>>>> https://www.rfc-editor.org/authors/rfc9472.html
>>>>>> https://www.rfc-editor.org/authors/rfc9472.txt
>>>>>> https://www.rfc-editor.org/authors/rfc9472.pdf
>>>>>> 
>>>>>> Diff file showing all changes made during AUTH48:
>>>>>> https://www.rfc-editor.org/authors/rfc9472-auth48diff.html
>>>>>> 
>>>>>> Diff files showing all changes:
>>>>>> https://www.rfc-editor.org/authors/rfc9472-diff.html
>>>>>> https://www.rfc-editor.org/authors/rfc9472-rfcdiff.html (side-by-side diff)
>>>>>> 
>>>>>> Note that it may be necessary for you to refresh your browser to view the
>> most recent version.
>>>>>> 
>>>>>> For the AUTH48 status of this document, please see:
>>>>>> https://www.rfc-editor.org/auth48/rfc9472
>>>>>> 
>>>>>> Thank you,
>>>>>> 
>>>>>> RFC Editor/st
>>>>>> 
>>>>>>> On Sep 16, 2023, at 9:04 AM, Eliot Lear <[e-mail]> wrote:
>>>>>>> 
>>>>>>> Sarah,
>>>>>>> 
>>>>>>> I believe that I have found several errors in the examples.  There are two
>> problems:
>>>>>>> 
>>>>>>> 1.  sbom-url should appear as part of an array of objects, and is not.
>>>>>>> 2.  There is one case where mudtx wasn’t used where it should have
>> been.
>>>>>>> @Rob, please check me on this.  This should correspond to "list sboms”
>> in the model.
>>>>>>> 
>>>>>>> In Section 5.1, first example, the change is adding the sboms array:
>>>>>>> 
>>>>>>> OLD:
>>>>>>> {
>>>>>>> "ietf-mud:mud": {
>>>>>>> "mud-version": 1,
>>>>>>> "extensions": [
>>>>>>> "transparency"
>>>>>>> ],
>>>>>>> "mudtx:transparency": {
>>>>>>> "sbom-url": "https://iot.example.com/info/modelX/sbom.json",
>>>>>>> "vuln-url" : [
>>>>>>> "https://iotd.example.com/info/modelX/csaf.json"
>>>>>>> ]
>>>>>>> },
>>>>>>> "mud-url": "https://iot.example.com/modelX.json",
>>>>>>> "mud-signature": "https://iot.example.com/modelX.p7s",
>>>>>>> "last-update": "2022-01-05T13:29:12+00:00",
>>>>>>> "cache-validity": 48,
>>>>>>> "is-supported": true,
>>>>>>> "systeminfo": "retrieving vuln and SBOM info via a cloud service",
>>>>>>> "mfg-name": "Example, Inc.",
>>>>>>> "documentation": "https://iot.example.com/doc/modelX",
>>>>>>> "model-name": "modelX"
>>>>>>> }
>>>>>>> }
>>>>>>> NEW:
>>>>>>> {
>>>>>>> "ietf-mud:mud": {
>>>>>>> "mud-version": 1,
>>>>>>> "extensions": [
>>>>>>> "transparency"
>>>>>>> ],
>>>>>>> "mudtx:transparency": {
>>>>>>> sboms: [ {
>>>>>>> "version-info": "1.2",
>>>>>>> "sbom-url": "https://iot.example.com/info/modelX/sbom.json"
>>>>>>> } ],
>>>>>>> "vuln-url" : [
>>>>>>> "https://iotd.example.com/info/modelX/csaf.json"
>>>>>>> ]
>>>>>>> },
>>>>>>> "mud-url": "https://iot.example.com/modelX.json",
>>>>>>> "mud-signature": "https://iot.example.com/modelX.p7s",
>>>>>>> "last-update": "2022-01-05T13:29:12+00:00",
>>>>>>> "cache-validity": 48,
>>>>>>> "is-supported": true,
>>>>>>> "systeminfo": "retrieving vuln and SBOM info via a cloud service",
>>>>>>> "mfg-name": "Example, Inc.",
>>>>>>> "documentation": "https://iot.example.com/doc/modelX",
>>>>>>> "model-name": "modelX"
>>>>>>> }
>>>>>>> }
>>>>>>> 
>>>>>>> Section 5.1, 2nd Example, same change:
>>>>>>> 
>>>>>>> 
>>>>>>> OLD:
>>>>>>> 
>>>>>>> {
>>>>>>> "ietf-mud:mud": {
>>>>>>> "mud-version": 1,
>>>>>>> "extensions": [
>>>>>>> "transparency"
>>>>>>> ],
>>>>>>> "mudtx:transparency": {
>>>>>>> "sbom-url": "https://iot.example.com/info/modelX/sbom.json"
>>>>>>> },
>>>>>>> "mud-url": "https://iot.example.com/modelX.json",
>>>>>>> "mud-signature": "https://iot.example.com/modelX.p7s",
>>>>>>> "last-update": "2022-01-05T13:29:12+00:00",
>>>>>>> "cache-validity": 48,
>>>>>>> "is-supported": true,
>>>>>>> "systeminfo": "retrieving only SBOM info via a cloud service",
>>>>>>> "mfg-name": "Example, Inc.",
>>>>>>> "documentation": "https://iot.example.com/doc/modelX",
>>>>>>> "model-name": "modelX"
>>>>>>> }
>>>>>>> }
>>>>>>> NEW:
>>>>>>> {
>>>>>>> "ietf-mud:mud": {
>>>>>>> "mud-version": 1,
>>>>>>> "extensions": [
>>>>>>> "transparency"
>>>>>>> ],
>>>>>>> "mudtx:transparency": {
>>>>>>> sboms: [ {
>>>>>>> "version-info": "1.2",
>>>>>>> "sbom-url": "https://iot.example.com/info/modelX/sbom.json"
>>>>>>> } ],
>>>>>>> },
>>>>>>> "mud-url": "https://iot.example.com/modelX.json",
>>>>>>> "mud-signature": "https://iot.example.com/modelX.p7s",
>>>>>>> "last-update": "2022-01-05T13:29:12+00:00",
>>>>>>> "cache-validity": 48,
>>>>>>> "is-supported": true,
>>>>>>> "systeminfo": "retrieving vuln and SBOM info via a cloud service",
>>>>>>> "mfg-name": "Example, Inc.",
>>>>>>> "documentation": "https://iot.example.com/doc/modelX",
>>>>>>> "model-name": "modelX"
>>>>>>> }
>>>>>>> }
>>>>>>> 
>>>>>>> Section 5.3:
>>>>>>> 
>>>>>>> OLD:
>>>>>>> {
>>>>>>> "ietf-mud:mud": {
>>>>>>> "mud-version": 1,
>>>>>>> "extensions": [
>>>>>>> "transparency"
>>>>>>> ],
>>>>>>> "ietf-mud-transparency:transparency": {
>>>>>>> "contact-info": "https://iot-device.example.com/contact-info.html",
>>>>>>> "vuln-url" : [
>>>>>>> "https://iotd.example.com/info/modelX/csaf.json"
>>>>>>> ]
>>>>>>> },
>>>>>>> "mud-url": "https://iot-device.example.com/modelX.json",
>>>>>>> "mud-signature": "https://iot-device.example.com/modelX.p7s",
>>>>>>> "last-update": "2021-07-09T06:16:42+00:00",
>>>>>>> "cache-validity": 48,
>>>>>>> "is-supported": true,
>>>>>>> "systeminfo": "retrieving vuln and SBOM info via a cloud service",
>>>>>>> "mfg-name": "Example, Inc.",
>>>>>>> "documentation": "https://iot-device.example.com/doc/modelX",
>>>>>>> "model-name": "modelX"
>>>>>>> }
>>>>>>> }
>>>>>>> NEW:
>>>>>>> {
>>>>>>> "ietf-mud:mud": {
>>>>>>> "mud-version": 1,
>>>>>>> "extensions": [
>>>>>>> "transparency"
>>>>>>> ],
>>>>>>> "mudtx:transparency": {
>>>>>>> "contact-info": "https://iot-device.example.com/contact-info.html",
>>>>>>> "vuln-url" : [
>>>>>>> "https://iotd.example.com/info/modelX/csaf.json"
>>>>>>> ]
>>>>>>> },
>>>>>>> "mud-url": "https://iot-device.example.com/modelX.json",
>>>>>>> "mud-signature": "https://iot-device.example.com/modelX.p7s",
>>>>>>> "last-update": "2021-07-09T06:16:42+00:00",
>>>>>>> "cache-validity": 48,
>>>>>>> "is-supported": true,
>>>>>>> "systeminfo": "retrieving vuln and SBOM info via a cloud service",
>>>>>>> "mfg-name": "Example, Inc.",
>>>>>>> "documentation": "https://iot-device.example.com/doc/modelX",
>>>>>>> "model-name": "modelX"
>>>>>>> }
>>>>>>> }
>>>>>>> Eliot
>>>>>>>> On 13 Sep 2023, at 22:34, Sarah Tarrant <[e-mail]> wrote:
>>>>>>>> 
>>>>>>>> Hello Eliot and Scott,
>>>>>>>> 
>>>>>>>> Thank you for your replies. We have updated the document accordingly,
>> and all of our questions for the authors have been addressed.
>>>>>>>> 
>>>>>>>> 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. We also need Rob’s AD approval of the change in Section
>> 1.3 and review of question #10 prior to moving forward.
>>>>>>>> 
>>>>>>>> Updated XML file:
>>>>>>>> http://www.rfc-editor.org/authors/rfc9472.xml
>>>>>>>> 
>>>>>>>> Updated output files:
>>>>>>>> https://www.rfc-editor.org/authors/rfc9472.html
>>>>>>>> https://www.rfc-editor.org/authors/rfc9472.txt
>>>>>>>> https://www.rfc-editor.org/authors/rfc9472.pdf
>>>>>>>> 
>>>>>>>> Diff file showing all changes made during AUTH48:
>>>>>>>> https://www.rfc-editor.org/authors/rfc9472-auth48diff.html
>>>>>>>> 
>>>>>>>> Diff files showing all changes:
>>>>>>>> https://www.rfc-editor.org/authors/rfc9472-diff.html
>>>>>>>> https://www.rfc-editor.org/authors/rfc9472-rfcdiff.html (side-by-side
>> diff)
>>>>>>>> 
>>>>>>>> Note that it may be necessary for you to refresh your browser to view
>> the most recent version.
>>>>>>>> 
>>>>>>>> For the AUTH48 status of this document, please see:
>>>>>>>> https://www.rfc-editor.org/auth48/rfc9472
>>>>>>>> 
>>>>>>>> Thank you,
>>>>>>>> 
>>>>>>>> RFC Editor/st
>>>>>>>> 
>>>>>>>>> On Sep 13, 2023, at 8:14 AM, Rose, Scott W. (Fed)
>> <[e-mail]> wrote:
>>>>>>>>> 
>>>>>>>>> Sarah,
>>>>>>>>> I am generally fine with the changes, specific replies below:
>>>>>>>>> 
>>>>>>>>> Thanks,
>>>>>>>>> Scott
>>>>>>>>> 
>>>>>>>>> On 13 Sep 2023, at 3:15, Eliot Lear wrote:
>>>>>>>>> 
>>>>>>>>>> Hi Sarah and thanks!  Please see below.
>>>>>>>>>> 
>>>>>>>>>>> On 12 Sep 2023, at 20:50, Sarah Tarrant <[e-mail]>
>> wrote:
>>>>>>>>>>> 
>>>>>>>>>>> Hello Eliot, Scott, and Rob*,
>>>>>>>>>>> 
>>>>>>>>>>> *Rob, as AD, please review the change in the last paragraph of
>> Section 1.3 and let us know if you approve. The change is best viewed in this diff
>> file: https://www.rfc-editor.org/authors/rfc9472-auth48diff.html. Also, please let
>> us know your thoughts on this question (note that RFCs 6242, 8341, and 8446
>> are included in the template at https://trac.ietf.org/trac/ops/wiki/yang-security-
>> guidelines):
>>>>>>>>>>> 
>>>>>>>>>>>> 10) <!-- [rfced] *[AD] Section 6: The Security Considerations
>> section does not
>>>>>>>>>>>> follow the requirements listed on
>>>>>>>>>>>> https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines, which
>> says
>>>>>>>>>>>> "This section MUST be patterned after the latest approved
>> template."
>>>>>>>>>>>> Please confirm if the current text is acceptable per the context of
>> the
>>>>>>>>>>>> document or if any further updates are needed in order to follow
>> the
>>>>>>>>>>>> template.
>>>>>>>>>>>> 
>>>>>>>>>>>> Also, please confirm if it is acceptable that RFCs 6242, 8341, and
>>>>>>>>>>>> 8446 are not listed in the Normative References section or if they
>>>>>>>>>>>> should be added.
>>>>>>>>>>>> —>
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> Eliot and Scott, thank you for your replies; we have updated the
>> document accordingly. We have a few followup questions:
>>>>>>>>>>> 
>>>>>>>>>>> 1) We added the sentence in ii) per your reply to this question. We
>> also added RFC 7231 as a normative reference. Please confirm that this is
>> correct. Or should it be informative instead?
>>>>>>>>>> 
>>>>>>>>>> That’s correct.
>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>>>> e) We note that RFCs 6991 and 7231 are only referenced in the
>> YANG
>>>>>>>>>>>>> module and not in the running text. In order to have a 1:1
>> matchup
>>>>>>>>>>>>> between the references section and the text, may we add an
>> introductory
>>>>>>>>>>>>> sentence before the YANG module that includes these citations
>> (option i)?
>>>>>>>>>>>>> Alternatively, you may reference all of the RFCs that are
>> mentioned
>>>>>>>>>>>>> (option ii). Please let us know your preference.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Perhaps:
>>>>>>>>>>>>> i)  This YANG module references [RFC6991] and [RFC7231].
>>>>>>>>>>>>> or
>>>>>>>>>>>>> ii) This YANG module references [RFC6991], [RFC7231],
>> [RFC7252],
>>>>>>>>>>>>> [RFC8520], and [RFC9110].
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> ii seems complete.
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 2) Regarding this question:
>>>>>>>>>>> 
>>>>>>>>>>>>> 11) <!--[rfced] Is this sentence intended to be an ordered list
>> (option A)
>>>>>>>>>>>>> or are "any change in a URL" and "any change to the authority
>>>>>>>>>>>>> section" the 2 risks that are being referred to (option B)?
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Original:
>>>>>>>>>>>>> To address either risk, any change in a URL, and in particular to
>> the
>>>>>>>>>>>>> authority section, two approaches may be used:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Perhaps:
>>>>>>>>>>>>> A) To address either risk, any change in a URL, and particularly
>> any change
>>>>>>>>>>>>> to the authority section, two approaches may be used:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> or
>>>>>>>>>>>>> 
>>>>>>>>>>>>> B) To address either risk, i.e., any change in a URL and, in
>> particular, to
>>>>>>>>>>>>> the authority section, two approaches may be used:
>>>>>>>>>>>>> -->
>>>>>>>>>>>> 
>>>>>>>>>>>> How about:
>>>>>>>>>>>> 
>>>>>>>>>>>>> (C)  To address either risk, any change in a URL, and in particular
>> to the
>>>>>>>>>>>>> authority section; two approaches may be used:
>>>>>>>>>>>> 
>>>>>>>>>>>> ?
>>>>>>>>>>> 
>>>>>>>>>>> We are still having trouble understanding this sentence. (Note that
>> the text before the semicolon in (C) is not a complete sentence.) Would
>> something like the following work?
>>>>>>>>>>> 
>>>>>>>>>>> Perhaps:
>>>>>>>>>>> Two approaches may be used to address these risks and any change
>> in a URL (particularly in the
>>>>>>>>>>> authority section):
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> Ok, having re-read the context, the authority section phrase is
>> redundant, so we can say:
>>>>>>>>>> 
>>>>>>>>>>> To address either of these risks or any tampering of a URL:
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> This seems fine.
>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 3) Regarding this question:
>>>>>>>>>>> 
>>>>>>>>>>>>> 15) <!-- [rfced] The following lines exceed the 72-character limit
>> for
>>>>>>>>>>>>> sourcecode. Please let us know how these lines can be modified.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Section 5.1 (1 character over):
>>>>>>>>>>>>> "systeminfo": "retrieving vuln and SBOM info via a cloud service",
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Section 5.2 (1 character over):
>>>>>>>>>>>>> "systeminfo": "mixed example: SBOM on device, vuln info in
>> cloud",
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Section 5.3 (2 characters over):
>>>>>>>>>>>>> "contact-info": "https://iot-device.example.com/contact-
>> info.html",
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Section 5.3 (1 character over):
>>>>>>>>>>>>> "systeminfo": "retrieving vuln and SBOM info via a cloud service",
>>>>>>>>>>>>> -->
>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> Would you mind out-denting these lines?
>>>>>>>>>>> 
>>>>>>>>>>> Please confirm that we updated these correctly. We moved the lines
>> in each example mentioned above one or two spaces (as appropriate) to the
>> left to meet the character limit, though we couldn’t not move the “{“ at the
>> beginning and end of each example as these were already at the left margin.
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> That’s okay.
>>>>>>>>>> 
>>>>>>>>>> Aside: this 72 character limit was VERY important when printers
>> could only print 80 columns, but that was on its way out even when *I* was a
>> student in the 80s (I never saw an actual line printer after college).
>>>>>>>>>> 
>>>>>>>>>> Regards,
>>>>>>>>>> 
>>>>>>>>>> Eliot
>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> ______________
>>>>>>>>>>> 
>>>>>>>>>>> Updated XML file:
>>>>>>>>>>> http://www.rfc-editor.org/authors/rfc9472.xml
>>>>>>>>>>> 
>>>>>>>>>>> Updated output files:
>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9472.html
>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9472.txt
>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9472.pdf
>>>>>>>>>>> 
>>>>>>>>>>> Diff file showing all changes made during AUTH48:
>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9472-auth48diff.html
>>>>>>>>>>> 
>>>>>>>>>>> Diff files showing all changes:
>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9472-diff.html
>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9472-rfcdiff.html (side-by-
>> side diff)
>>>>>>>>>>> 
>>>>>>>>>>> Note that it may be necessary for you to refresh your browser to
>> view the most recent version.
>>>>>>>>>>> 
>>>>>>>>>>> For the AUTH48 status of this document, please see:
>>>>>>>>>>> https://www.rfc-editor.org/auth48/rfc9472
>>>>>>>>>>> 
>>>>>>>>>>> Thank you,
>>>>>>>>>>> 
>>>>>>>>>>> RFC Editor/st
>>>>>>>>>>> 
>>>>>>>>>>>> On Sep 11, 2023, at 12:23 PM, Rose, Scott W. (Fed)
>> <scott.rose=[e-mail]> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>> On 8 Sep 2023, at 19:26, [e-mail] wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>>> Authors and *AD,
>>>>>>>>>>>>> 
>>>>>>>>>>>>> While reviewing this document during AUTH48, please resolve (as
>> necessary) the following questions, which are also in the XML file.
>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 17) <!-- [rfced] FYI: We have added expansions for the following
>> abbreviations
>>>>>>>>>>>>> per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review
>> each
>>>>>>>>>>>>> expansion in the document carefully to ensure correctness.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Access Control Lists (ACLs)
>>>>>>>>>>>>> Constrained Application Protocol (CoAP)
>>>>>>>>>>>>> Internet of Things (IoT)
>>>>>>>>>>>>> -->
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 18) <!-- [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.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Note that our script did not flag any words in particular, but this
>> should
>>>>>>>>>>>>> still be reviewed as a best practice.
>>>>>>>>>>>>> -->
>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> FWIW, I did a pass through to match against the NIST inclusive
>> language guidance and did not find anything that needed to be addressed.
>> Future changes may change that (not likely, but maybe).
>>>>>>>>>>>> 
>>>>>>>>>>>> Thanks
>>>>>>>>>>>> Scott
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> ==================================
>>>>>>>>>>>> Scott Rose NIST/CTL
>>>>>>>>>>>> [e-mail]
>>>>>>>>>>>> ph: [phone] (w)
>>>>>>>>>>>> [phone] (GoogleVoice)
>>>>>>>>>>>> ==================================
>>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> ==================================
>>>>>>>>> Scott Rose NIST/CTL
>>>>>>>>> [e-mail]
>>>>>>>>> ph: [phone] (w)
>>>>>>>>> [phone] (GoogleVoice)
>>>>>>>>> ==================================
>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>