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

[Sarah Tarrant <[e-mail]>]

Hello Eliot and Rob,

We have now received all necessary approvals and consider AUTH48 complete:
   https://www.rfc-editor.org/auth48/rfc9472

Thank you for your attention and guidance during the AUTH48 process. We will move this document forward in the publication process at this time.

Sincerely,
RFC Editor/st

> On Oct 3, 2023, at 12:50 AM, Eliot Lear <[e-mail]> wrote:
> 
> 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)
>>>>>>>>>>>> ==================================
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>> 
>> 
>