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

["Rose, Scott W. (Fed)" <[e-mail]>]

I do not have anything else to add to the edits/changes suggested (and 
Eliot’s responses).  I am ok with publishing after the edits.  As 
previously mentioned, I don’t see any edits needed for inclusive 
language.

Thanks,
Scott

On 11 Sep 2023, at 7:56, Eliot Lear wrote:

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


==================================
Scott Rose NIST/CTL
[e-mail]
ph: [phone] (w)
     [phone] (GoogleVoice)
==================================