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

[Eliot Lear <[e-mail]>]

Thanks, Rob.  @Sarah In the next day or three, I will do a deep read to confirm everything is ok.

Eliot

> On 14 Sep 2023, at 14:00, Rob Wilton (rwilton) <rwilton=[e-mail]> wrote:
> 
> 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)
>>> ==================================
>> 
>