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

[Sarah Tarrant <[e-mail]>]

> Begin forwarded message:
> 
> From: "Amanda Baber via RT" <[e-mail]>
> Subject: [IANA #1282204] [IANA] Re: [AD] AUTH48: RFC-to-be 9472 <draft-ietf-opsawg-sbom-access-18> for your review
> Date: September 20, 2023 at 6:03:00 PM CDT
> To: [e-mail]
> Reply-To: [e-mail]
> 
> Hi all,
> 
> This change is complete:
> 
> https://www.iana.org/assignments/yang-parameters
> 
> thanks,
> 
> Amanda Baber
> IANA Operations Manager
> 
> On Wed Sep 20 21:02:46 2023, [e-mail] wrote:
>> IANA,
>> 
>> Please make the following change in the “YANG Module Names” registry
>> at https://www.iana.org/assignments/yang-parameters. Note that there
>> are two entries for "ietf-mud”. This change should only be applied for
>> the one with this document as a reference.
>> 
>> OLD:
>> ietf-mud
>> 
>> NEW:
>> ietf-mud-transparency
>> 
>> Thank you,
>> RFC Editor/st
>> 
>>> On Sep 20, 2023, at 3:59 PM, 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)
>>>>>>>> ==================================
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>