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

[Eliot Lear <[e-mail]>]

[One for Rob Wilton below]

Hi RFC Editor!

> On 9 Sep 2023, at 01: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.
> 
> *AD, please review question #10 (re: Section 6).
> 
> 1) <!-- [rfced] This document's title and short title (that spans the
> header of the pdf) do not follow the style of other YANG RFCs
> (although we see that RFCs 8783 and 9132 are exceptions). For
> example:
> 
>  RFC 9094 - A YANG Data Model for Wavelength Switched Optical Networks
>             (WSONs)
>  RFC 9093 - A YANG Data Model for Layer 0 Types
>  RFC 9067 - A YANG Data Model for Routing Policy
> 
> Please consider the suggested updates below and let us know if one of
> these options is agreeable or if you prefer otherwise.
> 
> Document title
> Original:
>   Discovering and Retrieving Software Transparency and Vulnerability
>   Information
> 
> Perhaps:
> a) A YANG Data Model for Reporting Software Bills of Materials
>   (SBOMs) and Vulnerability Information
> or
> 
> b) A YANG Data Model Augmentation for Reporting Software Bills
>   of Materials (SBOMs) and Vulnerability Information

I like (a).

> 
> ...
> Short title
> Original:
>   Discovering SBOMs and Vuln. Info
> 
> Perhaps:
>   A YANG Data Model for SBOMs and Vuln. Info
> -->

That’s fine.

> 
> 
> 2) <!-- [rfced] Please insert any keywords (beyond those that appear in the
> title) for use on https://www.rfc-editor.org/search.
> -->
> 
I propose:

sbom, discovery, mud, vex, chaff

> 
> 3) <!--[rfced] Please clarify "A number of activities have been working
> to". Have the activities improved visibility (option A) or is
> this a work in progress (option B)?
> 
> Original:
>   A number of activities have been working to improve visibility to
>   what software is running on a system, and what vulnerabilities that
>   software may have [EO2021].
> 
> Perhaps:
> A) A number of activities have been effective in improving the visibility
>   of what software is running on a system and what vulnerabilities that
>   software may have [EO2021].
> 
> or
> 
> B) A number of activities are being implemented to improve the visibility
>   of what software is running on a system and what vulnerabilities that
>   software may have [EO2021].
> -->

How about (C)
> 
> C)) A number of activities taken place to improve the visibility
>   of what software is running on a system and what vulnerabilities that
>   software may have [EO2021].
> -->

> 
> 

> 4) <!--[rfced] May we replace "vulnerable" with "open" as follows to
> avoid redundancy?
> 
> Original:
>   *  Is this system vulnerable to a particular vulnerability?
> 
> Perhaps:
>   *  Is this system open to a particular vulnerability?
> —>

I think a better word is “susceptible".

> 
> 
> 5) <!--[rfced] Would you like to create a new section for the
> requirements language instead of including it at the end of
> Section 1? It would become Section 1.1 as follows:
> 
> Original:
>   Further queries may be necessary based on the content and structure of the
>   response.
> 
>   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
>   "OPTIONAL" in this document are to be interpreted as described in
>   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
>   capitals, as shown here.
> 
> Perhaps:
>   Further queries may be necessary based on the content and structure of the
>   response.
> 
> Section 1.1  Requirements Language
> 
>   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
>   "OPTIONAL" in this document are to be interpreted as described in
>   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
>   capitals, as shown here.
> -->
> 
> 

That would be fine.


> 6) <!--[rfced] May we change "rather than retrieving it twice" to "rather
> than the resource being retrieved twice" for clarity? Please let
> us know if this retains the intended meaning.


> 
> Original:
>   Network management systems retrieving this information MUST
>   take note that the identical resource is being retrieved
>   rather than retrieving it twice.
> 
> Perhaps:
>   Network management systems retrieving this information MUST
>   take note that the identical resource is being retrieved
>   rather than the resource being retrieved twice.
> -->

Hmm.  I suggest the following:

> Network management systems MUST take note of when the SBOM
> and vulnerability information are accessible via the same resource,
> and not retrieve the resource a second time.


> 
> 
> 7) <!--[rfced] Could the title of Section 3 be updated slightly to reduce
> redundancy? Please let us know if option A or B may be preferable.
> 
> Original:
>   The mud-transparency Extension Model Extension
> 
> Perhaps:
> A) The mud-transparency Extension
> 
> or
> 
> B) The mud-transparency Model Extension
> -->
> 

Let’s go for A.

> 
> 8) <!-- [rfced] For the benefit of international readership, may we update "N.B."
> to "Note that" as follows?
> 
> Original:
>   N.B., this schema extension is intended to be used wherever it might
>   be appropriate (e.g., not just MUD).
> 
> Perhaps:
>   Note that this schema extension is intended to be used wherever it
>   might be appropriate (e.g., not just with MUD).
> -->

That’s fine.

> 
> 
> 9) <!-- [rfced] Section 4. Please review the following questions about
> the YANG module and section title.
> 
> a) FYI: We updated one instance of "YANG model" to "YANG Data Model"
> in this section's title per guidance from Benoit Claise and the
> YANG Doctors, as "YANG module" and "YANG data model" are preferred.
> Please review.
> 
> Original:
>   The mud-sbom augmentation to the MUD YANG model
> 
> Current:
>   The mud-sbom Augmentation to the MUD YANG Data Model

That’s fine.

> 
> 
> b) Note that the YANG module has been updated per the formatting
> option of pyang.  Please let us know any concerns.
> 
> c) FYI: We added titles to the reference entries for RFCs 6991
> and 8520 for consistency.
> 
> d) May we include reference entries in the YANG module for
> RFCs 7231, 7252, and 9110 since these RFCs are mentioned in
> the description clauses?

All good with b, c, and d.

> 
> 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.


> 
> f) We note that RFC 7231 has been obsoleted by RFC 9110. May we replace
> RFC 7231 with RFC 9110 in the following instance?
> 
> Current:
>    "Use http (RFC 7231) (insecure) to retrieve SBOM information.
>     This method is NOT RECOMMENDED but may be unavoidable for
>     certain classes of deployment where TLS has not or
>     cannot be implemented.";
> -->
> 
> 

I think in this case, it is best to leave it as is, because we are indeed recommending against its use ;-)


> 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.

Rob, would you mind staring at this?

> 
> 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.
> -->
> 

I don’t see them referenced in the text.

> 
> 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:

?


> 
> 
> 12) <!-- [rfced] We have included some clarifications about the IANA
> text below.  In addition to reviewing those, please review all
> of the IANA-related updates carefully and let us know if any
> further updates are needed.
> 
> a) Section 7.2. FYI: We have added the defining RFCs for each of the registries
> as follows and have added the corresponding reference entries to the
> Normative References section.
> 
> Original:
>   The IANA is requested to add "transparency" to the MUD extensions
>   registry as follows:
> 
> Current:
>   IANA has added "transparency" to the "MUD Extensions" registry [RFC8520]
>   as follows:
> 
> ...
> Original:
>   The following YANG module should be registered in the "YANG Module
>   Names" registry:
> 
> Current:
>   IANA has registered the following YANG module in the "YANG Module
>   Names" registry [RFC6020]:
> 
> ...
> Original:
>  The following XML registration is requested:
> 
> Current:
>  The following URI has been registered in the "IETF XML Registry"
>  [RFC3688]:

All good.

> 
> b) Section 7.2. FYI: In the entry under the "YANG Module Names"
> registry, we removed "Registration Contact" since it is not listed
> in the registry, and we added "Maintained by IANA: N" since it is
> listed in the registry; please see
> https://www.iana.org/assignments/yang-parameters/.
> 
> Original:
>   Name:  ietf-mud
>   URN:  urn:ietf:params:xml:ns:yang:ietf-mud-transparency
>   Prefix:  mudtx
>   Registrant contact:  The IESG
>   Reference:  This memo
> 
> Current:
>   Name:  ietf-mud
>   URN:  urn:ietf:params:xml:ns:yang:ietf-mud-transparency
>   Maintained by IANA: N
>   Prefix:  mudtx
>   Reference:  RFC 9472

Ok

> 
> c) Section 7.3. FYI: We have added "Status: permanent" to the entry
> for the "Well-Known URIs" registry to match the IANA
> registry at https://www.iana.org/assignments/well-known-uris/.
> 
> Original:
>   URI suffix:  "sbom"
>   Change controller:  "IETF"
>   Specification document:  This memo
>   Related information:  See ISO/IEC 5962:2021 and SPDX.org
> 
> Current:
>   URI Suffix:  sbom
>   Change Controller:  IETF
>   Reference:  RFC 9472
>   Status: permanent
>   Related information:  See ISO/IEC 5962:2021 and SPDX.org
> -->
> 
> 

Ok

> 13) <!-- [rfced] References
> 
> a) We updated the title for reference [EO2021] to match the following
> URL: https://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/
> executive-order-on-improving-the-nations-cybersecurity/. Please let us know
> if this is correct or if the intension is to point to a different article
> (perhaps https://www.nist.gov/itl/executive-order-14028-improving-nations-
> cybersecurity).
> 
> Original:
>   [EO2021]   Biden, J., "Executive Order 14028, Improving the Nations
>              Cybersecurity", May 2021.
> 
> Current:
>   [EO2021]   Biden, J., "Executive Order on Improving the Nation's
>              Cybersecurity", EO 14028, May 2021.
> 
> 

Ok

> b) FYI: We updated the title of the reference [CycloneDX12] to match the
> title at "https://cyclonedx.org/docs/1.2/xml" and included a direct URL.
> Please let us know of any objections.
> 
> Original:
>   [CycloneDX12]
>              cyclonedx.org, "CycloneDX XML Reference v1.2", May 2020.
> 
> Current:
>   [CycloneDX12]
>              CycloneDX, "CycloneDX v1.2 XML Reference", Version 1.2.1,
> 	      <https://cyclonedx.org/docs/1.2/xml/>.
> -->

Ok, this one needs updating.  The reference should now be

[CycloneDX15] CycloneDX, “CycloneDX v1.5 JSON Reference”, Version 1.5,
<https://cyclonedx.org/docs/1.5/json>

And this will need updating in the introduction.  Time passes, eh?


> 
> 
> 14) <!-- [rfced] Throughout the text, the following terminology appears to be capitalized
> inconsistently. May we update to "Content-Type" to match past RFCs, including use in
> RFCs 7252, 8615, 8040, 9110?
> 
>   Content-Type vs. Content-type vs. content-type
> 

Yes.


> 
> 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?


> 16) <!-- [rfced] Please review the "type" attributes for the sourcecode elements
> in the XML file for correctness. If the current list of preferred values for
> "type" (https://www.rfc-editor.org/materials/sourcecode-types.txt) does not
> contain an applicable type, then feel free to suggest a new one.  Also,
> it is acceptable to leave the "type" attribute not set.
> -->
> 

You can use “json” for examples, yang tree for the yang tree, and yang for the yang.


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

All good.

> 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.

Ok.  I’ll do this on the next pass.

Thanks,

Eliot
> 
> Note that our script did not flag any words in particular, but this should
> still be reviewed as a best practice.
> -->
> 
> 
> Thank you.
> 
> RFC Editor/st/kc
> 
> 
> On Sep 8, 2023, at 4:23 PM, [e-mail] wrote:
> 
> *****IMPORTANT*****
> 
> Updated 2023/09/08
> 
> RFC Author(s):
> --------------
> 
> Instructions for Completing AUTH48
> 
> Your document has now entered AUTH48.  Once it has been reviewed and
> approved by you and all coauthors, it will be published as an RFC.
> If an author is no longer available, there are several remedies
> available as listed in the FAQ (https://www.rfc-editor.org/faq/).
> 
> You and you coauthors are responsible for engaging other parties
> (e.g., Contributors or Working Group) as necessary before providing
> your approval.
> 
> Planning your review
> ---------------------
> 
> Please review the following aspects of your document:
> 
> *  RFC Editor questions
> 
>  Please review and resolve any questions raised by the RFC Editor
>  that have been included in the XML file as comments marked as
>  follows:
> 
>  <!-- [rfced] ... -->
> 
>  These questions will also be sent in a subsequent email.
> 
> *  Changes submitted by coauthors
> 
>  Please ensure that you review any changes submitted by your
>  coauthors.  We assume that if you do not speak up that you
>  agree to changes submitted by your coauthors.
> 
> *  Content
> 
>  Please review the full content of the document, as this cannot
>  change once the RFC is published.  Please pay particular attention to:
>  - IANA considerations updates (if applicable)
>  - contact information
>  - references
> 
> *  Copyright notices and legends
> 
>  Please review the copyright notice and legends as defined in
>  RFC 5378 and the Trust Legal Provisions
>  (TLP – https://trustee.ietf.org/license-info/).
> 
> *  Semantic markup
> 
>  Please review the markup in the XML file to ensure that elements of
>  content are correctly tagged.  For example, ensure that <sourcecode>
>  and <artwork> are set correctly.  See details at
>  <https://authors.ietf.org/rfcxml-vocabulary>.
> 
> *  Formatted output
> 
>  Please review the PDF, HTML, and TXT files to ensure that the
>  formatted output, as generated from the markup in the XML file, is
>  reasonable.  Please note that the TXT will have formatting
>  limitations compared to the PDF and HTML.
> 
> 
> Submitting changes
> ------------------
> 
> To submit changes, please reply to this email using ‘REPLY ALL’ as all
> the parties CCed on this message need to see your changes. The parties
> include:
> 
>  *  your coauthors
> 
>  *  [e-mail] (the RPC team)
> 
>  *  other document participants, depending on the stream (e.g.,
>     IETF Stream participants are your working group chairs, the
>     responsible ADs, and the document shepherd).
> 
>  *  [e-mail], which is a new archival mailing list
>     to preserve AUTH48 conversations; it is not an active discussion
>     list:
> 
>    *  More info:
>       https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
> 
>    *  The archive itself:
>       https://mailarchive.ietf.org/arch/browse/auth48archive/
> 
>    *  Note: If only absolutely necessary, you may temporarily opt out
>       of the archiving of messages (e.g., to discuss a sensitive matter).
>       If needed, please add a note at the top of the message that you
>       have dropped the address. When the discussion is concluded,
>       [e-mail] will be re-added to the CC list and
>       its addition will be noted at the top of the message.
> 
> You may submit your changes in one of two ways:
> 
> An update to the provided XML file
> — OR —
> An explicit list of changes in this format
> 
> Section # (or indicate Global)
> 
> OLD:
> old text
> 
> NEW:
> new text
> 
> You do not need to reply with both an updated XML file and an explicit
> list of changes, as either form is sufficient.
> 
> We will ask a stream manager to review and approve any changes that seem
> beyond editorial in nature, e.g., addition of new text, deletion of text,
> and technical changes.  Information about stream managers can be found in
> the FAQ.  Editorial changes do not require approval from a stream manager.
> 
> 
> Approving for publication
> --------------------------
> 
> To approve your RFC for publication, please reply to this email stating
> that you approve this RFC for publication.  Please use ‘REPLY ALL’,
> as all the parties CCed on this message need to see your approval.
> 
> 
> Files
> -----
> 
> The files are available here:
>  https://www.rfc-editor.org/authors/rfc9472.xml
>  https://www.rfc-editor.org/authors/rfc9472.html
>  https://www.rfc-editor.org/authors/rfc9472.pdf
>  https://www.rfc-editor.org/authors/rfc9472.txt
> 
> Diff file of the text:
>  https://www.rfc-editor.org/authors/rfc9472-diff.html
>  https://www.rfc-editor.org/authors/rfc9472-rfcdiff.html (side by side)
> 
> Diff of the XML:
>  https://www.rfc-editor.org/authors/rfc9472-xmldiff1.html
> 
> The following files are provided to facilitate creation of your own
> diff files of the XML.
> 
> Initial XMLv3 created using XMLv2 as input:
>  https://www.rfc-editor.org/authors/rfc9472.original.v2v3.xml
> 
> XMLv3 file that is a best effort to capture v3-related format updates
> only:
>  https://www.rfc-editor.org/authors/rfc9472.form.xml
> 
> 
> Tracking progress
> -----------------
> 
> The details of the AUTH48 status of your document are here:
>  https://www.rfc-editor.org/auth48/rfc9472
> 
> Please let us know if you have any questions.
> 
> Thank you for your cooperation,
> 
> RFC Editor
> 
> --------------------------------------
> RFC9472 (draft-ietf-opsawg-sbom-access-18)
> 
> Title            : Discovering and Retrieving Software Transparency and Vulnerability Information
> Author(s)        : E. Lear, S. Rose
> WG Chair(s)      : Henk Birkholz, Joe Clarke, Tianran Zhou
> Area Director(s) : Warren Kumari, Robert Wilton
> 
> 
>