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

[[e-mail]]

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

...
Short title
Original:
   Discovering SBOMs and Vuln. Info

Perhaps:
   A YANG Data Model for SBOMs and Vuln. Info
-->


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


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


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


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


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


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


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


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


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?

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

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


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


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


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

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

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


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.


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


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


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",
-->


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


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


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