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

[Sarah Tarrant <[e-mail]>]

Hello Rob and Eliot,

Rob, 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). 

Eliot, we look forward to your review. 

We will await approvals from each of the parties listed at the AUTH48 status page prior to moving this document forward in the publication process.

Thank you,
RFC Editor/st

> On Sep 14, 2023, at 7:25 AM, Eliot Lear <[e-mail]> wrote:
> 
> 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)
>>>> ==================================
>>> 
>> 
>