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

[Eliot Lear <[e-mail]>]

Ok.  Sarah, do you have what you need?

Eliot

> On Oct 2, 2023, at 11:49, Rob Wilton (rwilton) <[e-mail]> wrote:
> 
> Hi Eliot,
> 
> That is fine.
> 
> Regards,
> Rob
> 
> 
>> -----Original Message-----
>> From: Eliot Lear <[e-mail]>
>> Sent: Thursday, September 28, 2023 3:05 PM
>> To: Rob Wilton (rwilton) <[e-mail]>
>> Cc: Sarah Tarrant <[e-mail]>; Rose, Scott W. (Fed)
>> <[e-mail]>; RFC Editor <[e-mail]>; opsawg-
>> [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
>> 
>> Ok, I’ve reviewed this.  I think in this instance, since we are talking about a JSON
>> example, and the JSON document ignores spaces and still parses, we can just
>> leave it as is.  I don’t think it’s necessary to reflow.  Are you okay with that Rob?
>> 
>> Eliot
>> 
>>> On Sep 27, 2023, at 12:32, Rob Wilton (rwilton) <[e-mail]> wrote:
>>> 
>>> Hi Sarah, Eliot,
>>> 
>>> Sorry for the delay.
>>> 
>>> Regarding the changes in 5.1 and 5.3:
>>> 
>>> Rather than outdenting, did we consider leveraging RFC 8792?  E.g., to cite a
>> random specific example, see the end of section 2.2.2 of
>> https://datatracker.ietf.org/doc/draft-ietf-netconf-crypto-types/
>>> 
>>> Example:
>>>  =============== NOTE: '\' line wrapping per RFC 8792 ================
>>> 
>>>  <rpc-reply message-id="101"
>>>    xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
>>>    <p10-csr xmlns="http://example.com/ns/example-crypto-types-usage">\
>>>  BASE64VALUE=</p10-csr>
>>>  </rpc-reply>
>>> 
>>> The advantage of this is that tooling can extract the example from the RFC
>> and still give a completely normal properly indented example.  I'm not sure
>> how many recent YANG RFCs have started to do this, but I think that this is what
>> I'm starting to more commonly see.
>>> 
>>> Thanks,
>>> Rob
>>> 
>>> 
>>>> -----Original Message-----
>>>> From: Sarah Tarrant <[e-mail]>
>>>> Sent: Friday, September 22, 2023 3:15 PM
>>>> To: Eliot Lear <[e-mail]>
>>>> Cc: Rob Wilton (rwilton) <[e-mail]>; Rose, Scott W. (Fed)
>>>> <[e-mail]>; RFC Editor <[e-mail]>; opsawg-
>>>> [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
>>>> 
>>>> Hi Eliot,
>>>> 
>>>> 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).
>>>> 
>>>> IANA has completed the update to the “YANG Module Names” registry.
>>>> 
>>>> We will move this document forward in the publication process once we
>> receive
>>>> approval from Rob on the changes to the sourcecode in Sections 5.1 and 5.3.
>>>> 
>>>> Thank you,
>>>> RFC Editor/st
>>>> 
>>>>> On Sep 21, 2023, at 1:32 AM, Eliot Lear <[e-mail]> wrote:
>>>>> 
>>>>> Hi Sarah,
>>>>> 
>>>>> I approve publication.  Thanks to you and the RPC for your work on this
>>>> document.
>>>>> 
>>>>> Eliot
>>>>> 
>>>>>> On 20 Sep 2023, at 22:59, Sarah Tarrant <[e-mail]> wrote:
>>>>>> 
>>>>>> Hi Eliot,
>>>>>> 
>>>>>> Thank you for spotting the issue with Section 7.2 and the IANA registry.
>> We
>>>> agree that "ietf-mud” should be updated to "ietf-mud-transparency” in
>> Section
>>>> 7.2 and have made that change. In a separate email, we will request that
>> IANA
>>>> update the “YANG Module Names” registry accordingly.
>>>>>> 
>>>>>> 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 19, 2023, at 12:42 AM, Eliot Lear <[e-mail]> wrote:
>>>>>>> 
>>>>>>> Hi Sarah,
>>>>>>> 
>>>>>>> I think I’ve caught one more small issue, but this is with the IANA registry.
>>>> Could you please check with them on the following:
>>>>>>> 
>>>>>>> In 7.2, I think the name field is supposed to be ietf-mud-transparency and
>>>> not ietf-mud.
>>>>>>> 
>>>>>>> After this matter is resolved, I can approve publication.
>>>>>>> 
>>>>>>> Thanks,
>>>>>>> 
>>>>>>> Eliot
>>>>>>> 
>>>>>>> 
>>>>>>>> On 18 Sep 2023, at 20:37, Sarah Tarrant <[e-mail]> wrote:
>>>>>>>> 
>>>>>>>> Hello Eliot and Rob*,
>>>>>>>> 
>>>>>>>> Elliot, thank you for your reply. We have updated the document
>>>> accordingly.
>>>>>>>> 
>>>>>>>> *Rob, as AD, please review and approve the changes to the sourcecode
>> in
>>>> Sections 5.1 and 5.3. These changes are best viewed in this diff file:
>>>> https://www.rfc-editor.org/authors/rfc9472-auth48diff.html.
>>>>>>>> 
>>>>>>>> We will await approvals from each of the parties listed above prior to
>>>> moving this document forward in the publication process.
>>>>>>>> 
>>>>>>>> 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 16, 2023, at 9:04 AM, Eliot Lear <[e-mail]> wrote:
>>>>>>>>> 
>>>>>>>>> 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)
>>>>>>>>>>> ==================================
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>> 
>