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

["Rob Wilton (rwilton)" <[e-mail]>]

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)
> >>>>>>> ==================================
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> >