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

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

Hi Eliot,

That is fine.

Regards,
Rob


> -----Original Message-----
> From: Eliot Lear <[e-mail]>
> Sent: Thursday, September 28, 2023 3:05 PM
> To: Rob Wilton (rwilton) <[e-mail]>
> Cc: Sarah Tarrant <[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
> 
> 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)
> >>>>>>>>> ==================================
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >