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

[Eliot Lear <[e-mail]>]

Sarah,

I believe that I have found several errors in the examples.  There are two problems:

1.  sbom-url should appear as part of an array of objects, and is not.
2.  There is one case where mudtx wasn’t used where it should have been.

@Rob, please check me on this.  This should correspond to "list sboms”  in the model.

In Section 5.1, first example, the change is adding the sboms array:

OLD:
{
 "ietf-mud:mud": {
   "mud-version": 1,
   "extensions": [
     "transparency"
   ],
   "mudtx:transparency": {
     "sbom-url": "https://iot.example.com/info/modelX/sbom.json",
     "vuln-url" : [
       "https://iotd.example.com/info/modelX/csaf.json"
     ]
   },
   "mud-url": "https://iot.example.com/modelX.json",
   "mud-signature": "https://iot.example.com/modelX.p7s",
   "last-update": "2022-01-05T13:29:12+00:00",
   "cache-validity": 48,
   "is-supported": true,
   "systeminfo": "retrieving vuln and SBOM info via a cloud service",
   "mfg-name": "Example, Inc.",
   "documentation": "https://iot.example.com/doc/modelX",
   "model-name": "modelX"
 }
}
NEW:
{
 "ietf-mud:mud": {
   "mud-version": 1,
   "extensions": [
     "transparency"
   ],
   "mudtx:transparency": {
     sboms: [ {
     "version-info": "1.2",
     "sbom-url": "https://iot.example.com/info/modelX/sbom.json"
     } ],
     "vuln-url" : [
       "https://iotd.example.com/info/modelX/csaf.json"
     ]
   },
   "mud-url": "https://iot.example.com/modelX.json",
   "mud-signature": "https://iot.example.com/modelX.p7s",
   "last-update": "2022-01-05T13:29:12+00:00",
   "cache-validity": 48,
   "is-supported": true,
   "systeminfo": "retrieving vuln and SBOM info via a cloud service",
   "mfg-name": "Example, Inc.",
   "documentation": "https://iot.example.com/doc/modelX",
   "model-name": "modelX"
 }
}

Section 5.1, 2nd Example, same change:

OLD:

{
  "ietf-mud:mud": {
    "mud-version": 1,
    "extensions": [
      "transparency"
    ],
    "mudtx:transparency": {
      "sbom-url": "https://iot.example.com/info/modelX/sbom.json"
    },
    "mud-url": "https://iot.example.com/modelX.json",
    "mud-signature": "https://iot.example.com/modelX.p7s",
    "last-update": "2022-01-05T13:29:12+00:00",
    "cache-validity": 48,
    "is-supported": true,
    "systeminfo": "retrieving only SBOM info via a cloud service",
    "mfg-name": "Example, Inc.",
    "documentation": "https://iot.example.com/doc/modelX",
    "model-name": "modelX"
  }
}
NEW:
{
 "ietf-mud:mud": {
   "mud-version": 1,
   "extensions": [
     "transparency"
   ],
   "mudtx:transparency": {
     sboms: [ {
     "version-info": "1.2",
     "sbom-url": "https://iot.example.com/info/modelX/sbom.json"
     } ],
   },
   "mud-url": "https://iot.example.com/modelX.json",
   "mud-signature": "https://iot.example.com/modelX.p7s",
   "last-update": "2022-01-05T13:29:12+00:00",
   "cache-validity": 48,
   "is-supported": true,
   "systeminfo": "retrieving vuln and SBOM info via a cloud service",
   "mfg-name": "Example, Inc.",
   "documentation": "https://iot.example.com/doc/modelX",
   "model-name": "modelX"
 }
}

Section 5.3:

OLD:
{
"ietf-mud:mud": {
"mud-version": 1,
"extensions": [
  "transparency"
],
"ietf-mud-transparency:transparency": {
  "contact-info": "https://iot-device.example.com/contact-info.html",
    "vuln-url" : [
      "https://iotd.example.com/info/modelX/csaf.json"
    ]
},
"mud-url": "https://iot-device.example.com/modelX.json",
"mud-signature": "https://iot-device.example.com/modelX.p7s",
"last-update": "2021-07-09T06:16:42+00:00",
"cache-validity": 48,
"is-supported": true,
"systeminfo": "retrieving vuln and SBOM info via a cloud service",
"mfg-name": "Example, Inc.",
"documentation": "https://iot-device.example.com/doc/modelX",
"model-name": "modelX"
}
}
NEW:
{
"ietf-mud:mud": {
"mud-version": 1,
"extensions": [
  "transparency"
],
"mudtx:transparency": {
  "contact-info": "https://iot-device.example.com/contact-info.html",
    "vuln-url" : [
      "https://iotd.example.com/info/modelX/csaf.json"
    ]
},
"mud-url": "https://iot-device.example.com/modelX.json",
"mud-signature": "https://iot-device.example.com/modelX.p7s",
"last-update": "2021-07-09T06:16:42+00:00",
"cache-validity": 48,
"is-supported": true,
"systeminfo": "retrieving vuln and SBOM info via a cloud service",
"mfg-name": "Example, Inc.",
"documentation": "https://iot-device.example.com/doc/modelX",
"model-name": "modelX"
}
}
Eliot
> On 13 Sep 2023, at 22:34, Sarah Tarrant <[e-mail]> wrote:
> 
> 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)
>> ==================================
> 
>