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

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

Hi Sarah,

The rewording on section 1.3 is fine with me.

For question 10, I approve of the current security text.  I have flagged this previously with the authors and there are good reasons for the text to deviate from the standard YANG security considerations template.

Regards,
Rob


> -----Original Message-----
> From: Sarah Tarrant <[e-mail]>
> Sent: 13 September 2023 21:35
> To: Rose, Scott W. (Fed) <[e-mail]>; Eliot Lear
> <lear=[e-mail]>
> Cc: Rob Wilton (rwilton) <[e-mail]>; RFC Editor <rfc-editor@rfc-
> editor.org>; [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
> 
> 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)
> > ==================================
>