Re: [auth48] [EXT] [AD] Re: AUTH48: RFC-to-be 9393 <draft-ietf-sacm-coswid-24> for your review

[Lynne Bartholomew <[e-mail]>]

Hi, Jess and Henk.

We have noted your approvals on the AUTH48 status page:

   https://www.rfc-editor.org/auth48/rfc9393

Thank you!

RFC Editor/lb

> From: Henk Birkholz <[e-mail]>
> Subject: Re: [EXT] [AD] Re: AUTH48: RFC-to-be 9393 <draft-ietf-sacm-coswid-24> for your review
> Date: June 1, 2023 at 7:52:42 AM PDT
> To: Lynne Bartholomew <[e-mail]>, Charles M Schmidt <[e-mail]>
> Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "Waltermire, David" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "Inacio, Christopher" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
> 
> Hi Lynne,
> 
> thanks for all the help. Ship it!
> 
> 
> Viele Grüße,
> 
> Henk

> On Jun 1, 2023, at 6:14 AM, [e-mail] wrote:
> 
> This looks good to me, Lynne. Thanks for helping us get it all done.
> 
> Jess
> 
> -----Original Message-----
> From: Lynne Bartholomew <[e-mail]>
> Sent: Tuesday, May 30, 2023 5:09 PM
> To: Charles Schmidt (MITRE) <[e-mail]>
> Cc: [e-mail]; [e-mail]; Jessica Fitzgerald-McKay (GOV) <[e-mail]>; Waltermire, David <[e-mail]>; [e-mail]; [e-mail]; Inacio, Christopher <[e-mail]>; [e-mail]; [e-mail]
> Subject: Re: [EXT] [AD] Re: AUTH48: RFC-to-be 9393 <draft-ietf-sacm-coswid-24> for your review
> 
> Hi, Charles.
> 
> We have made further updates per your notes below.
> 
> The latest files are posted here:
> 
>   https://www.rfc-editor.org/authors/rfc9393.txt
>   https://www.rfc-editor.org/authors/rfc9393.pdf
>   https://www.rfc-editor.org/authors/rfc9393.html
>   https://www.rfc-editor.org/authors/rfc9393.xml
>   https://www.rfc-editor.org/authors/rfc9393-diff.html
>   https://www.rfc-editor.org/authors/rfc9393-rfcdiff.html
>   https://www.rfc-editor.org/authors/rfc9393-auth48diff.html
>   https://www.rfc-editor.org/authors/rfc9393-lastdiff.html
>   https://www.rfc-editor.org/authors/rfc9393-lastrfcdiff.html
> 
>   https://www.rfc-editor.org/authors/rfc9393-xmldiff1.html
>   https://www.rfc-editor.org/authors/rfc9393-xmldiff2.html
> 
> Thank you!
> 
> RFC Editor/lb
> 
>> On May 25, 2023, at 12:48 PM, Charles M Schmidt <[e-mail]> wrote:
>> 
>> Hello Lynne,
>> 
>> Thank you for providing the updated drafts. The reordering looks great.
>> 
>> Regarding some of your other comments from earlier, we identified a few editorial tweaks we would like to make to improve clarity.
>> 
>> Section 2.9.1 - clarify the relationship between hash and thumbprint
>> OLD:
>> CoSWID adds explicit support for the representation of hash entries using algorithms that are
>> registered in the IANA "Named Information Hash Algorithm Registry" [IANA.named-information]
>> using the hash member (index 7) and the corresponding hash-entry type
>> 
>> NEW:
>> CoSWID adds explicit support for the representation of hash entries using algorithms that are
>> registered in the IANA "Named Information Hash Algorithm Registry" [IANA.named-information].
>> This array is used by both the hash (index 7) and thumbprint (index 34) values.
>> 
>> Section 2.9.2 - revise description of the location element
>> OLD:
>> location (index 23): The filesystem path where a file is expected to be located when installed or
>> copied. The location MUST be either relative to the location of the parent directory item
>> (preferred) or relative to the location of the CoSWID tag (as indicated in the location value in
>> the evidence entry map) if no parent is defined. The location MUST NOT include a file's name,
>> which is provided by the fs-name item.
>> 
>> NEW:
>> location (index 23): The filesystem path where a file is expected to be located when installed or
>> copied. The location MUST either be an absolute path, or a
>> path relative to the path value included in the parent directory item
>> (preferred), or a path relative to the location of the CoSWID tag if no
>> parent is defined. The location MUST NOT include a file's name,
>> which is provided by the fs-name item.
>> 
>> Section 2.9.2 - Add hash = 7 to the code:
>> OLD:
>> resource-entry = {
>> type => text,
>> * $$resource-extension,
>> global-attributes,
>> }
>> directory = 16
>> file = 17
>> process = 18
>> resource = 19
>> 
>> NEW:
>> resource-entry = {
>> type => text,
>> * $$resource-extension,
>> global-attributes,
>> }
>> hash = 7
>> directory = 16
>> file = 17
>> process = 18
>> resource = 19
>> 
>> Section 2.9.2 - Update the description of the hash item
>> OLD:
>> hash (index 7): A hash of the file as described in Section 2.9.1.
>> 
>> NEW:
>> hash (index 7): Value that provides a hash of a file. This item provides an
>> integrity measurement with respect to a specific file. See Section 2.9.1
>> for more details on the use of the hash-entry data structure.
>> 
>> Section 2.9.4 - clarify location description by acknowledging previous description and the different use in this location
>> OLD:
>> location (index 23): The absolute file path of the location of the CoSWID tag generated as
>> evidence. (Location values in filesystem-item instances in the payload can be expressed
>> relative to this location.)
>> 
>> NEW:
>> location (index 23): The filesystem path of the location of the CoSWID tag generated as
>> evidence. This path is always an absolute file path (unlike
>> the value of a location item found within a filesystem-item described
>> in Section 2.9.2, which can be either a relative path or an absolute path).
>> 
>> Please let us know if you have any questions or concerns about these changes. I believe the remaining questions you had are addressed by the clarification that descriptions are not being moved across sections, but just being re-ordered within them.
>> 
>> Thanks a bunch,
>> Charles
>> 
>> -----Original Message-----
>> From: Lynne Bartholomew <[e-mail]>
>> Sent: Wednesday, May 24, 2023 5:46 PM
>> To: Charles M Schmidt <[e-mail]>
>> Cc: [e-mail]; [e-mail]; [e-mail]; Waltermire, David <[e-mail]>; [e-mail]; [e-mail]; Inacio, Christopher <[e-mail]>; [e-mail]; [e-mail]
>> Subject: Re: [EXT] [AD] Re: AUTH48: RFC-to-be 9393 <draft-ietf-sacm-coswid-24> for your review
>> 
>> Hi, Charles.
>> 
>> We have ordered the index-number listings within each section, per your note below.  Please review our updates carefully, and let us know if anything is incorrect.
>> 
>> The latest files are posted here.  Please refresh your browser:
>> 
>>  https://www.rfc-editor.org/authors/rfc9393.txt
>>  https://www.rfc-editor.org/authors/rfc9393.pdf
>>  https://www.rfc-editor.org/authors/rfc9393.html
>>  https://www.rfc-editor.org/authors/rfc9393.xml
>>  https://www.rfc-editor.org/authors/rfc9393-diff.html
>>  https://www.rfc-editor.org/authors/rfc9393-rfcdiff.html
>>  https://www.rfc-editor.org/authors/rfc9393-auth48diff.html
>>  https://www.rfc-editor.org/authors/rfc9393-lastdiff.html
>>  https://www.rfc-editor.org/authors/rfc9393-lastrfcdiff.html
>> 
>>  https://www.rfc-editor.org/authors/rfc9393-xmldiff1.html
>>  https://www.rfc-editor.org/authors/rfc9393-xmldiff2.html
>> 
>> We will look forward to receiving the additional updates later on.
>> 
>> Thank you!
>> 
>> RFC Editor/lb
>> 
>>> On May 24, 2023, at 11:57 AM, Charles M Schmidt <[e-mail]> wrote:
>>> 
>>> Hi Lynne,
>>> 
>>> Thank you for confirming. We are just about set with our response to the other questions (one more outstanding detail to go). I hope to have the other items to you tomorrow.
>>> 
>>> Thanks,
>>> Charles
>>> 
>>> -----Original Message-----
>>> From: Lynne Bartholomew <[e-mail]>
>>> Sent: Wednesday, May 24, 2023 1:54 PM
>>> To: Charles M Schmidt <[e-mail]>
>>> Cc: [e-mail]; [e-mail]; [e-mail]; Waltermire, David <[e-mail]>; [e-mail]; [e-mail]; Inacio, Christopher <[e-mail]>; [e-mail]; [e-mail]
>>> Subject: Re: [EXT] [AD] Re: AUTH48: RFC-to-be 9393 <draft-ietf-sacm-coswid-24> for your review
>>> 
>>> Hi, Charles.
>>> 
>>> Regarding
>>> 
>>>> Overall, our intent was that, *within a given section*, the descriptions would appear in index order, but only within their own section since descriptions only appear in sections for which the code snippets specify the term and index. We never intended for any descriptions to be moved to different sections.
>>> 
>>> We did indeed misunderstand your request.  We will make the necessary corrections and email you again when we've finished.
>>> 
>>> Thank you for clarifying!
>>> 
>>> RFC Editor/lb
>>> 
>>>> On May 23, 2023, at 1:12 PM, Charles M Schmidt <[e-mail]> wrote:
>>>> 
>>>> Hello Lynne,
>>>> 
>>>> We are working on the edits to address the issues you identified. However, we have one question for you regarding your comment number 3:
>>>> 
>>>> =====
>>>> 3. In Section 2.9.4, we see the following:
>>>> 
>>>> date = 35
>>>> device-id = 36
>>>> 
>>>> ...
>>>> 
>>>> date (index 35): The date and time the information was collected
>>>> pertaining to the evidence item in epoch-based date/time format as
>>>> specified in Section 3.4.2 of [RFC8949].
>>>> 
>>>> device-id (index 36): The endpoint's string identifier from which
>>>> the evidence was collected.
>>>> 
>>>> If indices 35 and 36 are moved to a previous section, will this create confusion?  Should we add, somewhere in the text, one or more citations for Section 2.9.4, to point readers to more information regarding these two indices?
>>>> 
>>>> ======
>>>> 
>>>> Our question was why indices 35 and 36 were getting moved at all. Section 2.9.4 is where these two elements are listed in the code reference so it makes sense that they would be described in that section. Overall, our intent was that, *within a given section*, the descriptions would appear in index order, but only within their own section since descriptions only appear in sections for which the code snippets specify the term and index. We never intended for any descriptions to be moved to different sections. So the bottom line is we do not understand why indices 35 and 36 were being moved to a previous section in the first place. Could you explain? (And I apologize if my original request was unclear on this point.)
>>>> 
>>>> Thanks,
>>>> Charles
>>>> 
>>>> -----Original Message-----
>>>> From: Lynne Bartholomew <[e-mail]>
>>>> Sent: Thursday, May 11, 2023 3:30 PM
>>>> To: Charles M Schmidt <[e-mail]>
>>>> Cc: [e-mail]; [e-mail]; [e-mail]; Waltermire, David <[e-mail]>; [e-mail]; [e-mail]; Inacio, Christopher <[e-mail]>; [e-mail]; [e-mail]
>>>> Subject: Re: [EXT] [AD] Re: AUTH48: RFC-to-be 9393 <draft-ietf-sacm-coswid-24> for your review
>>>> 
>>>> Hi, Charles.
>>>> 
>>>> We started reordering the "(index ..)" listings in Sections 2.3, 2.7, 2.9.2, and 2.9.4, but we stopped after almost finishing the ordering in Section 2.3, because we have some follow-up questions that we would like to resolve before we continue:
>>>> 
>>>> 1. We see that this list in Section 2.3 does not include index 7.  Assuming that we should move the "hash (index 7)" entry from Section 2.9.2 to Section 2.3, should we also add "hash = 7" to the list, between the payload and corpus entries?
>>>> 
>>>> tag-id = 0
>>>> software-name = 1
>>>> entity = 2
>>>> evidence = 3
>>>> link = 4
>>>> software-meta = 5
>>>> payload = 6
>>>> corpus = 8
>>>> patch = 9
>>>> media = 10
>>>> supplemental = 11
>>>> tag-version = 12
>>>> software-version = 13
>>>> version-scheme = 14
>>>> 
>>>> = = = = =
>>>> 
>>>> 2. We also see two entries each for "media (index 10)" and "location (index 23)" in this document.  Should there only be one of each, or is it correct to have the two entries each for these two items?
>>>> 
>>>> = = = = =
>>>> 
>>>> 3. In Section 2.9.4, we see the following:
>>>> 
>>>> date = 35
>>>> device-id = 36
>>>> 
>>>> ...
>>>> 
>>>> date (index 35): The date and time the information was collected
>>>> pertaining to the evidence item in epoch-based date/time format as
>>>> specified in Section 3.4.2 of [RFC8949].
>>>> 
>>>> device-id (index 36): The endpoint's string identifier from which
>>>> the evidence was collected.
>>>> 
>>>> If indices 35 and 36 are moved to a previous section, will this create confusion?  Should we add, somewhere in the text, one or more citations for Section 2.9.4, to point readers to more information regarding these two indices?
>>>> 
>>>> = = = = =
>>>> 
>>>> We will wait to hear from you before proceeding.
>>>> 
>>>> Thank you!
>>>> 
>>>> RFC Editor/lb
>>>> 
>>>> 
>>>>> On May 10, 2023, at 1:41 PM, Charles M Schmidt <[e-mail]> wrote:
>>>>> 
>>>>> Hello Lynne,
>>>>> 
>>>>> Thank you very much for the updated copy of the document. In our final review, we noted two minor tweaks:
>>>>> 
>>>>> #1
>>>>> Section 1.1: The paragraph above and the paragraph below figure 1 are indented. These paragraphs should not be indented but should be the same indentation as the surrounding paragraphs.
>>>>> 
>>>>> #2
>>>>> In sections 2.3, 2.7, 2.9.2, and 2.9.4, the description of the items are almost but not quite in index order. (E.g., in 2.9.2 the description of index 7 is between indices 21 and 22; in 2.7 the description of index 10 is between indices 38 and 39.) It would probably be more intuitive for readers for the descriptions to be presented in index order, from lowest to greatest. Would it be possible to make this change?
>>>>> 
>>>>> Both of these are largely cosmetic at the end of the day, so if implementing them will be a problem then please disregard. However, if possible to implement these last-second changes, it would be nice. Please let me know if this is possible.
>>>>> 
>>>>> Thanks a bunch,
>>>>> Charles
>>>>> 
>>>>> -----Original Message-----
>>>>> From: Lynne Bartholomew <[e-mail]>
>>>>> Sent: Tuesday, May 9, 2023 6:09 PM
>>>>> To: Charles M Schmidt <[e-mail]>
>>>>> Cc: [e-mail]; [e-mail]; [e-mail]; Waltermire, David <[e-mail]>; [e-mail]; [e-mail]; Inacio, Christopher <[e-mail]>; [e-mail]; [e-mail]
>>>>> Subject: Re: [EXT] [AD] Re: AUTH48: RFC-to-be 9393 <draft-ietf-sacm-coswid-24> for your review
>>>>> 
>>>>> Hi, Charles.  Thank you for your latest reply!  We have further updated this document per your notes below.
>>>>> 
>>>>> The latest files are posted here (please refresh your browser):
>>>>> 
>>>>> https://www.rfc-editor.org/authors/rfc9393.txt
>>>>> https://www.rfc-editor.org/authors/rfc9393.pdf
>>>>> https://www.rfc-editor.org/authors/rfc9393.html
>>>>> https://www.rfc-editor.org/authors/rfc9393.xml
>>>>> https://www.rfc-editor.org/authors/rfc9393-diff.html
>>>>> https://www.rfc-editor.org/authors/rfc9393-rfcdiff.html
>>>>> https://www.rfc-editor.org/authors/rfc9393-auth48diff.html
>>>>> https://www.rfc-editor.org/authors/rfc9393-lastdiff.html
>>>>> https://www.rfc-editor.org/authors/rfc9393-lastrfcdiff.html
>>>>> 
>>>>> https://www.rfc-editor.org/authors/rfc9393-xmldiff1.html
>>>>> https://www.rfc-editor.org/authors/rfc9393-xmldiff2.html
>>>>> 
>>>>> Thanks again!
>>>>> 
>>>>> RFC Editor/lb
>>>>> 
>>>>>> On May 9, 2023, at 5:18 AM, Charles M Schmidt <[e-mail]> wrote:
>>>>>> 
>>>>>> Hello all,
>>>>>> 
>>>>>> Thanks for the follow up. Responses below:
>>>>>> 
>>>>>> 8) The indenting scheme shown in the PDF (it looks like it is a 2-level indent) looks good. Please go with what you proposed.
>>>>>> 
>>>>>> 24) We are not a fan of having to split the comment over two lines. We propose the following change, shortening the comment:
>>>>>> Section 2.10
>>>>>> OLD:
>>>>>> ; supplemental=11 ; already defined in the
>>>>>> ; "global map member" integer indices
>>>>>> 
>>>>>> NEW:
>>>>>> ; supplemental=11 ; already defined
>>>>>> 
>>>>>> 41) Missed and updated text normalization
>>>>>> Global:
>>>>>> OLD: (missed normalization from before)
>>>>>> version scheme name
>>>>>> 
>>>>>> NEW:
>>>>>> Version Scheme Name
>>>>>> 
>>>>>> Global: (XML Schema capitalization - we'll defer to W3C's conventions)
>>>>>> OLD:
>>>>>> XML schema
>>>>>> 
>>>>>> NEW:
>>>>>> XML Schema
>>>>>> 
>>>>>> Section 7: (suggest just re-using previously defined acronym in section 7)
>>>>>> OLD:
>>>>>> Cryptographic signatures can make any modification of the tag detectable, which is especially important if the integrity of the tag is important, such as when the tag is providing reference integrity measurements for files.
>>>>>> 
>>>>>> NEW:
>>>>>> Cryptographic signatures can make any modification of the tag detectable, which is especially important if the integrity of the tag is important, such as when the tag is providing RIMs for files.
>>>>>> 
>>>>>> 
>>>>>> I believe that covers everything. Thank you for the thorough review. Please let us know if you have any further questions or suggestions.
>>>>>> 
>>>>>> Take care,
>>>>>> Charles
>>>>>> 
>>>>>> -----Original Message-----
>>>>>> From: Lynne Bartholomew <[e-mail]>
>>>>>> Sent: Friday, May 5, 2023 4:41 PM
>>>>>> To: Charles M Schmidt <[e-mail]>
>>>>>> Cc: [e-mail]; [e-mail]; [e-mail]; Waltermire, David <[e-mail]>; [e-mail]; [e-mail]; Inacio, Christopher <[e-mail]>; [e-mail]; [e-mail]
>>>>>> Subject: Re: [EXT] [AD] Re: AUTH48: RFC-to-be 9393 <draft-ietf-sacm-coswid-24> for your review
>>>>>> 
>>>>>> Hi, Charles.
>>>>>> 
>>>>>> Thank you very much for the email and answers to our many questions!
>>>>>> 
>>>>>> We have updated this document per your notes below.
>>>>>> 
>>>>>> We have a few follow-up items for you:
>>>>>> 
>>>>>> Regarding this request to indent the first "Note:" paragraph:  xml2rfcv3 does not permit us to indent the <aside> text one level in this particular case; we could only either have no indentation or two levels of indentation.  Please review the current layout, and let us know if you prefer that the <aside> text be outdented two levels.
>>>>>> 
>>>>>>> 8) All "Note:" entries should be <aside>s.
>>>>>>> Section 1.1: The paragraph that starts with "Note" should be an <aside>. Also, it should be indented but without a lead bullet. The Note paragraph is a second paragraph that is part of the preceding bullet on Software Upgrading.
>>>>>> 
>>>>>> = = = = =
>>>>>> 
>>>>>> Regarding this item from our question 24):
>>>>>> 
>>>>>>> OLD:
>>>>>>> ; supplemental=11 ; this is already defined earlier
>>>>>>> 
>>>>>>> NEW:
>>>>>>> ; supplemental=11 ; already defined in the "global map member" integer indices
>>>>>> 
>>>>>> The new comment text made the line length too long.  We made it a multi-line comment.  Please review, and let us know if the line breaks should be placed differently.
>>>>>> 
>>>>>> = = = = =
>>>>>> 
>>>>>> Question 41):  We did not see a reply regarding the use of the lowercase form "version scheme name" in running text.  Please let us know any concerns.
>>>>>> 
>>>>>> = = = = =
>>>>>> 
>>>>>> Regarding this item from our question 41):
>>>>>> 
>>>>>>> OLD:
>>>>>>> XML Schema
>>>>>>> 
>>>>>>> NEW:
>>>>>>> XML schema
>>>>>> 
>>>>>> Apologies for not noticing earlier that, with one exception, [W3C.REC-xmlschema-2-20041028] uses "XML Schema".  Would you like this document to follow the capitalization style in [W3C.REC-xmlschema-2-20041028] or stay with "XML schema"?
>>>>>> 
>>>>>> = = = = =
>>>>>> 
>>>>>> Regarding this item from question 41):
>>>>>> 
>>>>>>> OLD:
>>>>>>> Remote Attestation, which requires a link between reference integrity measurements (RIM) and Attester-produced event logs that complement attestation evidence [I-D.ietf-rats-architecture].
>>>>>>> 
>>>>>>> NEW:
>>>>>>> Remote Attestation, which requires a link between Reference Integrity Manifests (RIM) and Attester-produced event logs that complement attestation evidence [I-D.ietf-rats-architecture].
>>>>>> 
>>>>>> We have updated this document to use "Reference Integrity Manifests (RIMs)".  Please let us know if "reference integrity measurements" in Section 7 should be updated.
>>>>>> 
>>>>>> = = = = =
>>>>>> 
>>>>>> The latest files are posted here.  Please refresh your browser:
>>>>>> 
>>>>>> https://www.rfc-editor.org/authors/rfc9393.txt
>>>>>> https://www.rfc-editor.org/authors/rfc9393.pdf
>>>>>> https://www.rfc-editor.org/authors/rfc9393.html
>>>>>> https://www.rfc-editor.org/authors/rfc9393.xml
>>>>>> https://www.rfc-editor.org/authors/rfc9393-diff.html
>>>>>> https://www.rfc-editor.org/authors/rfc9393-rfcdiff.html
>>>>>> https://www.rfc-editor.org/authors/rfc9393-auth48diff.html
>>>>>> https://www.rfc-editor.org/authors/rfc9393-lastdiff.html
>>>>>> https://www.rfc-editor.org/authors/rfc9393-lastrfcdiff.html
>>>>>> 
>>>>>> https://www.rfc-editor.org/authors/rfc9393-xmldiff1.html
>>>>>> https://www.rfc-editor.org/authors/rfc9393-xmldiff2.html
>>>>>> 
>>>>>> Thanks again for your help!
>>>>>> 
>>>>>> RFC Editor/lb
>>>>>> 
>>>>>>> On May 4, 2023, at 9:08 AM, Charles M Schmidt <[e-mail]> wrote:
>>>>>>> 
>>>>>>> Hello,
>>>>>>> 
>>>>>>> Thank you for the feedback. I've included responses to all questions in this email.
>>>>>>> 
>>>>>>> 1) This question is directed at Roman
>>>>>>> 
>>>>>>> 2) Please add the zip code for Jessica:
>>>>>>> Author' Addresses:
>>>>>>> OLD:
>>>>>>> Jessica Fitzgerald-McKay
>>>>>>> National Security Agency
>>>>>>> 9800 Savage Road
>>>>>>> Ft. Meade, Maryland
>>>>>>> United States of America
>>>>>>> 
>>>>>>> NEW:
>>>>>>> Jessica Fitzgerald-McKay
>>>>>>> National Security Agency
>>>>>>> 9800 Savage Road
>>>>>>> Ft. Meade, Maryland 20755
>>>>>>> United States of America
>>>>>>> 
>>>>>>> 3) Email of 5/2 noted that this question is removed.
>>>>>>> 
>>>>>>> 4) Agree with proposed change:
>>>>>>> Abstract:
>>>>>>> 
>>>>>>> OLD:
>>>>>>> CoSWID supports a similar set of semantics and features as SWID tags, as well as new semantics that  allow CoSWIDs to describe additional types of information, all in a  more memory efficient format.
>>>>>>> 
>>>>>>> NEW:
>>>>>>> CoSWID supports a set of semantics and features that are similar to those for SWID tags, as well as new semantics that allow CoSWIDs to describe additional types of information, all in a more memory-efficient format.
>>>>>>> 
>>>>>>> 5) Agree with proposed change:
>>>>>>> Section 1.1
>>>>>>> 
>>>>>>> OLD:
>>>>>>> The SWID specification and supporting guidance provided in NIST  Internal Report (NISTIR) 8060: Guidelines for the Creation of  Interoperable SWID Tags [SWID-GUIDANCE] defines four types of SWID tags: primary, patch, corpus, and supplemental.  The following text  is paraphrased from these sources.
>>>>>>> 
>>>>>>> NEW:
>>>>>>> The SWID specification and supporting guidance provided in NIST Internal Report (NISTIR) 8060 ("Guidelines for the Creation of Interoperable Software Identification (SWID) Tags") [SWID-GUIDANCE] define four types of SWID tags: primary, patch, corpus, and supplemental. The following text is paraphrased from these sources.
>>>>>>> 
>>>>>>> 6) Text is correct as is. A primary tag is indicated by not setting any of the other indices for other tags. As such, it does not need its own index. Primary tags are described in section 1.1. NO CHANGE.
>>>>>>> 
>>>>>>> 7) Agree with proposed text (with a slight change in the comma position at the end):
>>>>>>> Section 1.1:
>>>>>>> 
>>>>>>> OLD:
>>>>>>> Tags are deployed and previously deployed tags that are typically removed (indicated by an  "x" prefix) at each lifecycle stage, as follows:
>>>>>>> 
>>>>>>> NEW:
>>>>>>> Tags are deployed, and previously deployed tags are typically removed (indicated by an "x" prefix), at each lifecycle stage as follows:
>>>>>>> 
>>>>>>> 8) All "Note:" entries should be <aside>s.
>>>>>>> Section 1.1: The paragraph that starts with "Note" should be an <aside>. Also, it should be indented but without a lead bullet. The Note paragraph is a second paragraph that is part of the preceding bullet on Software Upgrading.
>>>>>>> 
>>>>>>> OLD:
>>>>>>>      - Software Upgrading. As a software component is upgraded to a
>>>>>>> new version, new primary and supplemental tags replace
>>>>>>> existing tags, enabling timely and accurate tracking of
>>>>>>> updates to software inventory. While not illustrated in the
>>>>>>> figure, a corpus tag can also provide information about the
>>>>>>> upgrade installer and dependencies that need to be installed
>>>>>>> before the upgrade.
>>>>>>> 
>>>>>>> Note: In the context of software tagging software patching and
>>>>>>> updating differ in an important way. When installing a patch, a set
>>>>>>> of file modifications are made to pre-installed software which do
>>>>>>> not alter the version number or the descriptive metadata of an
>>>>>>> installed software component. An update can also make a set of file
>>>>>>> modifications, but the version number or the descriptive metadata of
>>>>>>> an installed software component are changed.
>>>>>>> 
>>>>>>> NEW:
>>>>>>>      - Software Upgrading. As a software component is upgraded to a
>>>>>>> new version, new primary and supplemental tags replace
>>>>>>> existing tags, enabling timely and accurate tracking of
>>>>>>> updates to software inventory. While not illustrated in the
>>>>>>> figure, a corpus tag can also provide information about the
>>>>>>> upgrade installer and dependencies that need to be installed
>>>>>>> before the upgrade.
>>>>>>> 
>>>>>>> Note: In the context of software tagging software patching and
>>>>>>> updating differ in an important way. When installing a patch, a set
>>>>>>> of file modifications are made to pre-installed software which do
>>>>>>> not alter the version number or the descriptive metadata of an
>>>>>>> installed software component. An update can also make a set of file
>>>>>>> modifications, but the version number or the descriptive metadata of
>>>>>>> an installed software component are changed.
>>>>>>> 
>>>>>>> Section 3: Make the whole paragraph that starts with "Note" an <aside>.
>>>>>>> 
>>>>>>> Section 6.2.4: Make the sentence that starts with "Note:" an <aside>. Only this sentence should be an aside.
>>>>>>> 
>>>>>>> 9) Agree with proposed text:
>>>>>>> Section 2:
>>>>>>> OLD:
>>>>>>> The integer values are defined in a registry  specific to the kind of value; the text values are not intended for  interchange and exclusively meant for private use as defined in  Section 6.2.2.
>>>>>>> 
>>>>>>> NEW:
>>>>>>> The integer values are defined in a registry specific to the kind of value; the text values are not intended for interchange and are exclusively meant for private use as defined in Section 6.2.2.
>>>>>>> 
>>>>>>> 10) Types need to be updated:
>>>>>>> Global (in the xml lines 362, 366, 371, 382, 567, 735, 759, 830, 995, 1089, 1105, 1197, 1214)):
>>>>>>> OLD:
>>>>>>> <sourcecode type="cddl">
>>>>>>> 
>>>>>>> NEW:
>>>>>>> <sourcecode type="cddl" name="coswid-exposition.cddl">
>>>>>>> 
>>>>>>> XML line 1243:
>>>>>>> OLD:
>>>>>>> <sourcecode type="cddl" markers="true">
>>>>>>> 
>>>>>>> NEW:
>>>>>>> <sourcecode type="cddl" name="concise-swid-tag.cddl" markers="true">
>>>>>>> 
>>>>>>> XML line 2900:
>>>>>>> OLD:
>>>>>>> <sourcecode type="cddl" markers="true">
>>>>>>> 
>>>>>>> NEW:
>>>>>>> <sourcecode type="cddl" name="sign1.cddl" markers="true">
>>>>>>> 
>>>>>>> XML line 2938:
>>>>>>> OLD:
>>>>>>> <sourcecode type="cddl" markers="true">
>>>>>>> 
>>>>>>> NEW:
>>>>>>> <sourcecode type="cddl" name="sign.cddl" markers="true">
>>>>>>> 
>>>>>>> XML line 2999:
>>>>>>> OLD:
>>>>>>> <sourcecode type="cddl" markers="true">
>>>>>>> 
>>>>>>> NEW:
>>>>>>> <sourcecode type="cddl" name="tags.cddl" markers="true">
>>>>>>> 
>>>>>>> 11) The author comment has been resolved and can be removed.
>>>>>>> 
>>>>>>> 12) This is not a verbatim quote. The quotation marks should be removed.
>>>>>>> Section 2.1:
>>>>>>> OLD:
>>>>>>> The CDDL "text" type is represented in CBOR as a major type 3, which  represents "a string of Unicode characters that [are] encoded as UTF-8 [RFC3629]" (see Section 3.1 of [RFC8949]).
>>>>>>> 
>>>>>>> NEW:
>>>>>>> The CDDL "text" type is represented in CBOR as a major type 3, which represents a string of Unicode characters that [are] encoded as UTF-8 [RFC3629] (see Section 3.1 of [RFC8949]).
>>>>>>> 
>>>>>>> 13) We request no change. Unlike the entity-entry and link-entry values, the version-scheme is relatively straightforward and doesn't have or need a section dedicated to it. We feel a reference from section 4.1 is unnecessary and (since only a small portion of that section deals with version-scheme) potentially confusing.
>>>>>>> 
>>>>>>> 14) The MUST NOT only applies to the "right part" of the value in 6.7. Proposing the following change to avoid ambiguity.
>>>>>>> Section 2.3:
>>>>>>> OLD:
>>>>>>> A textual tag-id MUST NOT contain a sequence of two underscores ("__", see Section 6.7).
>>>>>>> 
>>>>>>> NEW:
>>>>>>> A textual tag-id value MUST NOT contain a sequence of two underscores ("__"). This is because a sequence of two underscores is used to separate the TAG_CREATOR_REGID value and UNIQUE_ID value in a Software Identifier and a sequence of two underscores in a tag-id value could create ambiguity when parsing this identifier. See Section 6.7.
>>>>>>> 
>>>>>>> 15) Replace confusing parenthetical
>>>>>>> Section 2.3:
>>>>>>> 
>>>>>>> OLD:
>>>>>>> - version-scheme (index 14): An integer or textual value representing the versioning scheme used for the software-version item, as an integer label with text escape (Section 2, for the "Version Scheme" registry Section 4.1).
>>>>>>> 
>>>>>>> NEW:
>>>>>>> - version-scheme (index 14): An integer or textual value representing the versioning scheme used for the software-version item, as an integer label with text escape. For the "Version Scheme" values, see Section 4.1.
>>>>>>> 
>>>>>>> 16) Agree with proposed change.
>>>>>>> Section 2.3
>>>>>>> 
>>>>>>> OLD:
>>>>>>> link (index 4): Provides a means to establish relationship arcs between the tag and another items.
>>>>>>> 
>>>>>>> NEW:
>>>>>>> link (index 4):  Provides a means to establish relationship arcs between the tag and another item.
>>>>>>> 
>>>>>>> 17) Delete the confusing sentence.
>>>>>>> Section 2.4
>>>>>>> 
>>>>>>> OLD:
>>>>>>> If all of the corpus, patch, and supplemental items are "false", or if the corpus item is set to "true", then a software-version item MUST be included with a value set to the version of the software component. This ensures that primary and corpus tags have an identifiable software version.
>>>>>>> 
>>>>>>> NEW:
>>>>>>> If all of the corpus, patch, and supplemental items are "false", or if the corpus item is set to "true", then a software-version item MUST be included with a value set to the version of the software component.
>>>>>>> 
>>>>>>> 18) Agree with proposed change.
>>>>>>> Section 2.6:
>>>>>>> 
>>>>>>> OLD:
>>>>>>> role (index 33): An integer or textual value (integer label with text escape, see Section 2) representing the relationship(s) between the entity, and this tag or the referenced software component.
>>>>>>> 
>>>>>>> NEW:
>>>>>>> role (index 33):  An integer or textual value (integer label with text escape; see Section 2) representing the relationship(s) between the entity and this tag or the referenced software component.
>>>>>>> 
>>>>>>> 19) Should be 256..65536.
>>>>>>> Section 2.7:
>>>>>>> 
>>>>>>> OLD:
>>>>>>> $rel /= -356..65536 / text
>>>>>>> 
>>>>>>> NEW:
>>>>>>> $rel /= -256..65536 / text
>>>>>>> 
>>>>>>> 20) Rephrase two bullets:
>>>>>>> Section 2.7:
>>>>>>> 
>>>>>>> OLD:
>>>>>>> - a URI-like expression with "swid:" as the scheme refers to another SWID or CoSWID by the referenced tag's tag-id. This expression needs to be resolved in the context of the endpoint by software that can lookup other SWID or CoSWID tags. For example, "swid:2df9de35-0aff-4a86-ace6-f7dddd1ade4c" references the tag with the tag-id value "2df9de35-0aff-4a86-ace6-f7dddd1ade4c".
>>>>>>> 
>>>>>>> - a URI-like expression with "swidpath:" as the scheme, which refers to another software tag via an XPATH query [W3C.REC-xpath20-20101214] that matches items in that tag (Section 5.2). This scheme is provided for compatibility with [SWID]. This specification does not define how to resolve an XPATH query in the context of CBOR, see Section 5.2.
>>>>>>> 
>>>>>>> NEW:
>>>>>>> - a URI-like expression with "swid:" as the scheme refers to another SWID or CoSWID by the referenced tag's tag-id. This expression needs to be resolved in the context of the endpoint by software that can lookup other SWID or CoSWID tags. For example, "swid:2df9de35-0aff-4a86-ace6-f7dddd1ade4c" references the tag with the tag-id value "2df9de35-0aff-4a86-ace6-f7dddd1ade4c". See Section 5.1 for guidance on the "swid" expression.
>>>>>>> 
>>>>>>> - a URI-like expression with "swidpath:" as the scheme, which refers to another software tag via an XPATH query [W3C.REC-xpath20-20101214] that matches items in that tag (Section 5.2). This scheme is provided for compatibility with [SWID]. This specification does not define how to resolve an XPATH query in the context of CBOR. See Section 5.2 for guidance on the "swidpath" expression.
>>>>>>> 
>>>>>>> 21) Agree with proposed changes.
>>>>>>> Section 2.7:
>>>>>>> *  ownership (index 39): An integer or textual value (integer label
>>>>>>> with text escape, see Section 2, for the "Software ID Link
>>>>>>> Ownership Values" registry Section 4.3) used when the "href" item
>>>>>>> references another software component to indicate the degree of
>>>>>>> ownership between the software component referenced by the CoSWID
>>>>>>> tag and the software component referenced by the link.
>>>>>>> ...
>>>>>>> *  rel (index 40): An integer or textual value that (integer label
>>>>>>> with text escape, see Section 2, for the "Software ID Link Link
>>>>>>> Relationship Values" registry Section 4.3) identifies the
>>>>>>> relationship between this CoSWID and the target resource
>>>>>>> identified by the "href" item.
>>>>>>> ...
>>>>>>> *  use (index 42): An integer or textual value (integer label with
>>>>>>> text escape, see Section 2, for the "Software ID Link Link
>>>>>>> Relationship Values" registry Section 4.3) used to determine if
>>>>>>> the referenced software component has to be installed before
>>>>>>> installing the software component identified by the COSWID tag.
>>>>>>> 
>>>>>>> NEW:
>>>>>>> *  ownership (index 39):  An integer or textual value (integer label
>>>>>>> with text escape; see Section 2).  See Section 4.3 for the list
>>>>>>> of values available for this item.  This item is used when the
>>>>>>> href item references another software component to indicate the
>>>>>>> degree of ownership between the software component referenced by
>>>>>>> the CoSWID tag and the software component referenced by the link.
>>>>>>> ...
>>>>>>> *  rel (index 40):  An integer or textual value (integer label with
>>>>>>> text escape; see Section 2).  See Section 4.4 for the list of
>>>>>>> values available for this item.  This item identifies the
>>>>>>> relationship between this CoSWID and the target resource
>>>>>>> identified by the href item.
>>>>>>> ...
>>>>>>> *  use (index 42):  An integer or textual value (integer label with
>>>>>>> text escape; see Section 2).  See Section 4.5 for the list of
>>>>>>> values available for this item.  This item is used to determine
>>>>>>> if the referenced software component has to be installed before
>>>>>>> installing the software component identified by the CoSWID tag.
>>>>>>> 
>>>>>>> 22) Change i.e. to e.g.
>>>>>>> Section 2.8:
>>>>>>> OLD:
>>>>>>> Examples of an entitlement-key might include a  serial number, product key, or license key.  For values that  relate to a given software component install (i.e., license key),  a supplemental tag will typically contain this information.
>>>>>>> 
>>>>>>> NEW:
>>>>>>> Examples of an entitlement-key might include a serial number, product key, or license key.  For values that relate to a given software component install (e.g., license key),  a supplemental tag will typically contain this information.
>>>>>>> 
>>>>>>> 23) "$$software-meta-extension" is correct
>>>>>>> Section 2.8:
>>>>>>> 
>>>>>>> OLD:
>>>>>>> $$meta-extension: This CDDL socket can be used to extend the software-meta-entry group model. See Section 2.2.
>>>>>>> 
>>>>>>> NEW:
>>>>>>> $$software-meta-extension: This CDDL socket can be used to extend the software-meta-entry group model. See Section 2.2.
>>>>>>> 
>>>>>>> 24) 65536 is correct
>>>>>>> Section 2.10:
>>>>>>> 
>>>>>>> OLD:
>>>>>>> $rel /= -256..64436 / text
>>>>>>> 
>>>>>>> NEW:
>>>>>>> $rel /= -256..65536 / text
>>>>>>> 
>>>>>>> OLD:
>>>>>>> ; supplemental=11 ; this is already defined earlier
>>>>>>> 
>>>>>>> NEW:
>>>>>>> ; supplemental=11 ; already defined in the "global map member" integer indices
>>>>>>> 
>>>>>>> 25) Revised text
>>>>>>> Section 3:
>>>>>>> 
>>>>>>> OLD:
>>>>>>> Note: Multiple of the corpus, patch, and supplemental items can have  values set as "true".  The rules above provide a means to determine  the tag's type in such a case.  For example, a SWID or CoSWID tag for  a patch installer might have both corpus and patch items set to  "true".  In such a case, the tag is a "Corpus Tag".  The tag  installed by this installer would have only the patch item set to  "true", making the installed tag type a "Patch Tag".
>>>>>>> 
>>>>>>> NEW:
>>>>>>> Note: It is possible for some or all of the corpus, patch, and supplemental items to simultaneously have values set as "true". The rules above provide a means to determine the tag's type in such a case.  For example, a SWID or CoSWID tag for a patch installer might have both corpus and patch items set to "true".  In such a case, the tag is a "Corpus Tag".  The tag installed by this installer would have only the patch item set to "true", making the installed tag type a "Patch Tag".
>>>>>>> 
>>>>>>> 26) Agree with proposed text
>>>>>>> Section 4:
>>>>>>> 
>>>>>>> OLD:
>>>>>>> This section defines a number of kinds of indexed label values that  are maintained in a registry each (Section 6).
>>>>>>> 
>>>>>>> NEW:
>>>>>>> This section defines multiple kinds of indexed label values that are maintained in several IANA registries.  See Section 6 for details.
>>>>>>> 
>>>>>>> 27) Agree with proposed text
>>>>>>> Table 6:
>>>>>>> 
>>>>>>> OLD:
>>>>>>> | 10    | supersedes        | The link references another           |
>>>>>>> |       |                   | software that this software           |
>>>>>>> |       |                   | replaces.  A patch tag (see           |
>>>>>>> ...
>>>>>>> 
>>>>>>> NEW:
>>>>>>> | 10    | supersedes        | The link references other software   |
>>>>>>> |       |                   | (e.g., an older software version)    |
>>>>>>> |       |                   | that this software replaces.  A path tag (see   |
>>>>>>> ...
>>>>>>> 
>>>>>>> 28) Agree with proposed text:
>>>>>>> Section 6.2.1:
>>>>>>> 
>>>>>>> OLD:
>>>>>>> This allows values -1 to -24 to be expressed as a single  uint_8t in CBOR, and values -25 to -256 to be expressed using an  additional uint_8t in CBOR.
>>>>>>> 
>>>>>>> NEW:
>>>>>>> This allows values -1 to -24 to be expressed as a single uint8_t in CBOR, and values -25 to -256 to be expressed using an additional uint8_t in CBOR.
>>>>>>> 
>>>>>>> 29) Agree with proposed text:
>>>>>>> Sections 6.2.4 through 6.2.8
>>>>>>> 
>>>>>>> OLD:
>>>>>>> Initial registrations for the "Software ID Version Scheme Values"
>>>>>>> registry are provided below, which are derived from the textual  version scheme names defined in [SWID].
>>>>>>> ...
>>>>>>> Initial registrations for the "Software ID Entity Role Values"
>>>>>>> registry are provided below, which are derived from the textual  entity role names defined in [SWID].
>>>>>>> ...
>>>>>>> Initial registrations for the "Software ID Link Ownership Values"
>>>>>>> registry are provided below, which are derived from the textual  entity role names defined in [SWID].
>>>>>>> ...
>>>>>>> Initial registrations for the "Software ID Link Relationship Values"
>>>>>>> registry are provided below, which are derived from the link  relationship values defined in [SWID].
>>>>>>> ...
>>>>>>> Initial registrations for the "Software ID Link Use Values" registry  are provided below, which are derived from the link relationship  values defined in [SWID].
>>>>>>> 
>>>>>>> NEW:
>>>>>>> Initial registrations for the "Software ID Version Scheme Values"
>>>>>>> registry are provided below and are derived from the textual version scheme names defined in [SWID].
>>>>>>> ...
>>>>>>> Initial registrations for the "Software ID Entity Role Values"
>>>>>>> registry are provided below and are derived from the textual entity role names defined in [SWID].
>>>>>>> ...
>>>>>>> Initial registrations for the "Software ID Link Ownership Values"
>>>>>>> registry are provided below and are derived from the textual entity role names defined in [SWID].
>>>>>>> ...
>>>>>>> Initial registrations for the "Software ID Link Relationship Values"
>>>>>>> registry are provided below and are derived from the link relationship values defined in [SWID].
>>>>>>> ...
>>>>>>> Initial registrations for the "Software ID Link Use Values" registry are provided below and are derived from the link relationship values defined in [SWID].
>>>>>>> 
>>>>>>> 30) Use "software-version item"
>>>>>>> Section 6.2.4
>>>>>>> 
>>>>>>> OLD:
>>>>>>> define a value space for the corresponding version item that is
>>>>>>> 
>>>>>>> NEW:
>>>>>>> define a value space for the corresponding software-version item that is
>>>>>>> 
>>>>>>> 31) Change to underscore
>>>>>>> Sections 7 and 8
>>>>>>> 
>>>>>>> OLD:
>>>>>>> COSE-Sign1-coswid<payload>
>>>>>>> 
>>>>>>> NEW:
>>>>>>> COSE_Sign1-coswid<payload>
>>>>>>> 
>>>>>>> OLD:
>>>>>>> COSE-Sign-coswid<payload>
>>>>>>> 
>>>>>>> NEW:
>>>>>>> COSE_Sign-coswid<payload>
>>>>>>> 
>>>>>>> 32) Agree with proposed removal of extraneous space.
>>>>>>> Section 7:
>>>>>>> 
>>>>>>> OLD:
>>>>>>> signature : bstr -->
>>>>>>> 
>>>>>>> NEW:
>>>>>>> signature: bstr -->
>>>>>>> 
>>>>>>> 33) Agree with proposed text:
>>>>>>> Section 8:
>>>>>>> 
>>>>>>> OLD:
>>>>>>> Consecutively, the CBOR tag for CoSWID tags  defined in Table 21 SHOULD be used in conjunction with CBOR data  items that are a CoSWID tags.
>>>>>>> 
>>>>>>> NEW:
>>>>>>> Consequently, the CBOR tag defined by this document (Table 21) for CoSWID tags SHOULD be used in conjunction with CBOR data items that are CoSWID tags.
>>>>>>> 
>>>>>>> 34) Rephrase
>>>>>>> Section 8
>>>>>>> 
>>>>>>> OLD:
>>>>>>> a tagged CoSWID tag
>>>>>>> 
>>>>>>> NEW:
>>>>>>> a CBOR-tagged CoSWID tag
>>>>>>> 
>>>>>>> 35) Agree with proposed text
>>>>>>> Section 9:
>>>>>>> 
>>>>>>> OLD:
>>>>>>> A signed CoSWID tag (see Section 7) whose signature has been  validated can be relied upon to be unchanged since it was signed.
>>>>>>> 
>>>>>>> NEW:
>>>>>>> A signed CoSWID tag (see Section 7) whose signature has been validated can be relied upon to be unchanged since the time at which it was signed.
>>>>>>> 
>>>>>>> 36) Agree with the first proposed text.
>>>>>>> Section 9:
>>>>>>> 
>>>>>>> OLD:
>>>>>>> A certification path between a trust anchor and a certificate  including a public key enabling the validation of a tag signature can  realize the assessment of trustworthiness of an authoritative tag.
>>>>>>> 
>>>>>>> NEW:
>>>>>>> A certification path between a trust anchor and a certificate, including a public key enabling the validation of a tag signature, can realize the assessment of trustworthiness of an authoritative tag.
>>>>>>> 
>>>>>>> 37) Reword
>>>>>>> Section 9:
>>>>>>> 
>>>>>>> OLD:
>>>>>>> This requires an association between the signature and the  tag's entity item associated corresponding to the software provider.
>>>>>>> 
>>>>>>> NEW:
>>>>>>> This requires verifying that party that signed the tag is the same party given in the software-creator role of the tag's entity item.
>>>>>>> 
>>>>>>> 38) Replace with "limited to"
>>>>>>> Section 9:
>>>>>>> 
>>>>>>> OLD:
>>>>>>> Access to the collection of an endpoint's CoSWID tags needs to be appropriately controlled to authorized applications and users using an appropriate access control mechanism.
>>>>>>> 
>>>>>>> NEW:
>>>>>>> Access to the collection of an endpoint's CoSWID tags needs to be limited to authorized applications and users using an appropriate access control mechanism.
>>>>>>> 
>>>>>>> 39) Agree with proposed text
>>>>>>> References:
>>>>>>> 
>>>>>>> OLD:
>>>>>>> [W3C.REC-css3-mediaqueries-20120619]
>>>>>>>      Rivoal, F., Ed., "Media Queries", W3C REC REC-css3-mediaqueries-20120619, W3C REC-css3-mediaqueries-20120619, 19 June 2012, <https://www.w3.org/TR/2012/REC-css3-mediaqueries-20120619/>.
>>>>>>> 
>>>>>>> NEW:
>>>>>>> [W3C.REC-css3-mediaqueries-20120619]
>>>>>>>      Rivoal, F., Ed., "Media Queries", W3C REC REC-css3-mediaqueries-20120619, W3C REC-css3-mediaqueries-20120619, 19 June 2012, <https://www.w3.org/TR/mediaqueries-3/>.
>>>>>>> 
>>>>>>> 40) Document was reviewed for inclusive language. Authors did not identify any other issues. In looking for a replacement for "whitespace", none of the proposed replacements were seen as adequate because they were not sufficiently comprehensive to include all the types of characters that fall under the general term of "whitespace". If you have a suggestion we would be open to using it, but currently do not have an adequate replacement.
>>>>>>> 
>>>>>>> 41) Normalizations:
>>>>>>> Global:
>>>>>>> 
>>>>>>> OLD:
>>>>>>> URI-scheme
>>>>>>> 
>>>>>>> NEW:
>>>>>>> URI scheme
>>>>>>> 
>>>>>>> * Note: one instance of "URI-scheme" is in a URL, and thus should not be changed.
>>>>>>> 
>>>>>>> OLD:
>>>>>>> XPATH
>>>>>>> 
>>>>>>> NEW:
>>>>>>> XPath
>>>>>>> 
>>>>>>> OLD:
>>>>>>> Private Use
>>>>>>> 
>>>>>>> NEW:
>>>>>>> private use
>>>>>>> 
>>>>>>> * NOTE: one instance of "Private Use" is in a section title and should not be changed.
>>>>>>> 
>>>>>>> OLD:
>>>>>>> XML Schema
>>>>>>> 
>>>>>>> NEW:
>>>>>>> XML schema
>>>>>>> 
>>>>>>> * NOTE: one instance of "XML Schema" is in the title of a reference and it should not be changed.
>>>>>>> 
>>>>>>> OLD:
>>>>>>> indexes
>>>>>>> 
>>>>>>> NEW:
>>>>>>> indices
>>>>>>> 
>>>>>>> OLD:
>>>>>>> "href" item
>>>>>>> 
>>>>>>> NEW:
>>>>>>> href item
>>>>>>> 
>>>>>>> OLD:
>>>>>>> "role" item
>>>>>>> 
>>>>>>> NEW
>>>>>>> role item
>>>>>>> 
>>>>>>> Section 1:
>>>>>>> 
>>>>>>> OLD:
>>>>>>> Remote Attestation, which requires a link between reference integrity measurements (RIM) and Attester-produced event logs that complement attestation evidence [I-D.ietf-rats-architecture].
>>>>>>> 
>>>>>>> NEW:
>>>>>>> Remote Attestation, which requires a link between Reference Integrity Manifests (RIM) and Attester-produced event logs that complement attestation evidence [I-D.ietf-rats-architecture].
>>>>>>> 
>>>>>>> I believe this addresses all of your questions and feedback. Please let me know if I missed anything or if any part of this response is unclear.
>>>>>>> 
>>>>>>> Thanks a bunch,
>>>>>>> Charles
>>>>>>> 
>>>>>>> -----Original Message-----
>>>>>>> From: [e-mail] <[e-mail]>
>>>>>>> Sent: Friday, April 14, 2023 4:46 PM
>>>>>>> To: [e-mail]; [e-mail]; Charles M Schmidt <[e-mail]>; Waltermire, David <[e-mail]>
>>>>>>> Cc: [e-mail]; [e-mail]; [e-mail]; Inacio, Christopher <[e-mail]>; [e-mail]; [e-mail]
>>>>>>> Subject: [EXT] [AD] Re: AUTH48: RFC-to-be 9393 <draft-ietf-sacm-coswid-24> for your review
>>>>>>> 
>>>>>>> Authors and *Roman (AD),
>>>>>>> 
>>>>>>> While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the XML file.
>>>>>>> 
>>>>>>> *AD, please see question #1.
>>>>>>> 
>>>>>>> 1) <!-- [rfced] *AD - This document underwent two version changes since version -22, which we edited last year; we later received notifications for versions -23 and -24.
>>>>>>> 
>>>>>>> We manually incorporated the updates by looking at the diff between version -22 and version -24 on the Datatracker.
>>>>>>> 
>>>>>>> Please review the changes to Sections 5 and 6 carefully, and let us know if you approve. -->
>>>>>>> 
>>>>>>> 
>>>>>>> 2) <!-- [rfced] Authors' Addresses:  Jessica Fitzgerald-McKay's contact information is the only listing that does not include a postal code.
>>>>>>> If you would like us to include a postal code, please provide it.
>>>>>>> (We see "20755" used in
>>>>>>> draft-ietf-rats-tpm-based-network-device-attest.)
>>>>>>> 
>>>>>>> Original:
>>>>>>> Jessica Fitzgerald-McKay
>>>>>>> National Security Agency
>>>>>>> 9800 Savage Road
>>>>>>> Ft. Meade, Maryland
>>>>>>> United States of America
>>>>>>> Email: [e-mail] -->
>>>>>>> 
>>>>>>> 
>>>>>>> 3) <!-- [rfced]  As it appears that "LocalWords" as listed after the Acknowledgments section in the original XML file refers to "key words" as defined in RFC 2119, we list them here as key words and have added them to our database record for this document.
>>>>>>> 
>>>>>>> If this is incorrect, please insert any keywords (beyond those that appear in the title) for use on <https://www.rfc-editor.org/search>,
>>>>>>> and we will update the <keyword> settings here and in our database record accordingly.
>>>>>>> 
>>>>>>> Original:
>>>>>>> LocalWords:  SWID verifier TPM filesystem discoverable CoSWID -->
>>>>>>> 
>>>>>>> 
>>>>>>> 4) <!-- [rfced] Abstract:  To what does "similar" refer in this sentence?  If the suggested text is not correct, please provide clarifying text.
>>>>>>> 
>>>>>>> Original:
>>>>>>> CoSWID supports a similar set of
>>>>>>> semantics and features as SWID tags, as well as new semantics that  allow CoSWIDs to describe additional types of information, all in a  more memory efficient format.
>>>>>>> 
>>>>>>> Suggested:
>>>>>>> CoSWID supports a set of
>>>>>>> semantics and features that are similar to those for SWID tags, as  well as new semantics that allow CoSWIDs to describe additional  types of information, all in a more memory-efficient format. -->
>>>>>>> 
>>>>>>> 
>>>>>>> 5) <!-- [rfced] Section 1.1:  Because we see "paraphrased from these sources", we changed "defines" to "define" in the sentence that precedes it.  If this is incorrect, please provide clarifying text.
>>>>>>> 
>>>>>>> Original:
>>>>>>> The SWID specification and supporting guidance provided in NIST  Internal Report (NISTIR) 8060: Guidelines for the Creation of  Interoperable SWID Tags [SWID-GUIDANCE] defines four types of SWID
>>>>>>> tags: primary, patch, corpus, and supplemental.  The following text  is paraphrased from these sources.
>>>>>>> 
>>>>>>> Currently:
>>>>>>> The SWID specification and supporting guidance provided in NIST  Internal Report (NISTIR) 8060 ("Guidelines for the Creation of  Interoperable Software Identification (SWID) Tags") [SWID-GUIDANCE]  define four types of SWID tags: primary, patch, corpus, and  supplemental.  The following text is paraphrased from these sources. -->
>>>>>>> 
>>>>>>> 
>>>>>>> 6) <!-- [rfced] Section 1.1:  Section 2.3 does not contain a description of the primary tag type.  We also see that the primary tag type does not have an index number, as do the other three types.
>>>>>>> 
>>>>>>> Please confirm that (1) the lack of a description for the primary tag type in Section 2.3 will not be an issue for readers and (2) the primary tag type should not have an index number.
>>>>>>> 
>>>>>>> Original ("four tags types" has been changed to "four tag types"):
>>>>>>> A detailed description of the four
>>>>>>> tags types is provided in Section 2.3. -->
>>>>>>> 
>>>>>>> 
>>>>>>> 7) <!-- [rfced] Section 1.1:  This sentence did not parse.  We changed "that are typically removed" to "are typically removed".  If this is incorrect, please provide clarifying text.
>>>>>>> 
>>>>>>> Original:
>>>>>>> Tags are deployed and
>>>>>>> previously deployed tags that are typically removed (indicated by an  "x" prefix) at each lifecycle stage, as follows:
>>>>>>> 
>>>>>>> Currently:
>>>>>>> Tags are deployed, and
>>>>>>> previously deployed tags are typically removed (indicated by an "x"
>>>>>>> prefix) at each lifecycle stage, as follows: -->
>>>>>>> 
>>>>>>> 
>>>>>>> 8) <!-- [rfced] Please review whether any of the separate "Note:"
>>>>>>> paragraphs in this document should be in the <aside> element.
>>>>>>> <aside> is defined as "a container for content that is semantically less important or tangential to the content that surrounds it"
>>>>>>> (https://authors.ietf.org/en/rfcxml-vocabulary#aside) -->
>>>>>>> 
>>>>>>> 
>>>>>>> 9) <!-- [rfced] Section 2:  It appears that one or more words are missing from this sentence.  Should "and exclusively meant" be "and are exclusively meant"?  If not, please provide clarifying text.
>>>>>>> 
>>>>>>> Original:
>>>>>>> The integer values are defined in a registry  specific to the kind of value; the text values are not intended for  interchange and exclusively meant for private use as defined in  Section 6.2.2. -->
>>>>>>> 
>>>>>>> 
>>>>>>> 10) <!-- [rfced] Please review the "type" attribute of each sourcecode element in the XML file to ensure 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, please let us know.
>>>>>>> 
>>>>>>> Also, please review the remaining two instances of the artwork element.  Should any of the artwork elements be tagged as sourcecode or another type of element?
>>>>>>> 
>>>>>>> Please note that (1) for the ABNF in Section 6.7, we changed artwork to sourcecode with type="abnf" and (2) we changed the instances of sourcecode types "cddl;example" to "cddl", as "cddl;example" is not included on <https://www.rfc-editor.org/materials/sourcecode-types.txt>.
>>>>>>> Please let us know any concerns. -->
>>>>>>> 
>>>>>>> 
>>>>>>> 11) <!-- [rfced] Please let us know if any updates are needed regarding this author comment as seen in the original approved document.
>>>>>>> 
>>>>>>> Original:
>>>>>>> Hmm, duplicate detection doesn't work in CDDL tool here. -->
>>>>>>> 
>>>>>>> 
>>>>>>> 12) <!-- [rfced] Section 2.1:  Because this text is quoted, we searched RFCs 3629 and 8949 but could not find this text in either RFC.  To avoid possible reader confusion, may we either rephrase as suggested or remove the quotes?
>>>>>>> 
>>>>>>> Original:
>>>>>>> The CDDL "text" type is represented in CBOR as a major type 3, which  represents "a string of Unicode characters that [are] encoded as
>>>>>>> UTF-8 [RFC3629]" (see Section 3.1 of [RFC8949]).
>>>>>>> 
>>>>>>> Suggested (per RFC 8949):
>>>>>>> The CDDL "text" type is represented in CBOR as a major type 3, which  represents a string of Unicode characters that are "encoded as
>>>>>>> UTF-8 [RFC3629]" (see Section 3.1 of [RFC8949]). -->
>>>>>>> 
>>>>>>> 
>>>>>>> 13) <!-- [rfced] Table 2:  All "$" entries in this table, except for $version-scheme, are indirectly cited in their respective subsections of Section 4.
>>>>>>> 
>>>>>>> Per the pattern of indirect citations used for the other entries (where the other entries point to Sections 2.6 ("The entity-entry
>>>>>>> Map") and 2.7 ("The link-entry Map")), may we update the first sentence of Section 4.1 so that the sentence cites Section 2.3 ("The concise-swid-tag Map")?
>>>>>>> 
>>>>>>> Original (Table 2 and Section 4.1):
>>>>>>> | version-scheme   | $version-scheme | Section 4.1 |
>>>>>>> ...
>>>>>>> The following table contains a set of values for use in the concise-  swid-tag group's version-scheme item.
>>>>>>> 
>>>>>>> Suggested (Section 4.1):
>>>>>>> The following table contains a set of values for use in the concise-  swid-tag group's version-scheme item (see Section 2.3). -->
>>>>>>> 
>>>>>>> 
>>>>>>> 14) <!-- [rfced] Section 2.3:  This sentence seems to contradict the cited information in Section 6.7.  If the text below is correct as is, please confirm that "... MUST NOT contain a sequence of two underscores" and "... are connected with a double underscore (_)"
>>>>>>> will be clear to readers.
>>>>>>> 
>>>>>>> Original:
>>>>>>> A textual
>>>>>>> tag-id MUST NOT contain a sequence of two underscores ("__", see
>>>>>>> Section 6.7).
>>>>>>> 
>>>>>>> From Section 6.7:
>>>>>>> If the tag-id item's
>>>>>>> value is expressed as a 16-byte binary string, the UNIQUE_ID MUST be  represented using the UUID string representation defined in [RFC4122]  including the "urn:uuid:" prefix.
>>>>>>> 
>>>>>>> The TAG_CREATOR_REGID and the UNIQUE_ID are connected with a double  underscore (_), without any other connecting character or whitespace. -->
>>>>>>> 
>>>>>>> 
>>>>>>> 15) <!-- [rfced] Section 2.3:  We had trouble following the meaning of the parenthetical phrase in this sentence.  Also, we could not find a '"Version Scheme" registry'; this appears to refer to the "Software ID Version Scheme Values" registry, as mentioned a few lines after this sentence.
>>>>>>> 
>>>>>>> If the suggested text is not correct, please provide text that clarifies the meaning of "(Section 2, for the "Version Scheme"
>>>>>>> registry Section 4.1)".
>>>>>>> 
>>>>>>> Original:
>>>>>>> *  version-scheme (index 14): An integer or textual value
>>>>>>> representing the versioning scheme used for the software-version
>>>>>>> item, as an integer label with text escape (Section 2, for the
>>>>>>> "Version Scheme" registry Section 4.1).
>>>>>>> 
>>>>>>> Suggested:
>>>>>>> *  version-scheme (index 14): An integer or textual value
>>>>>>> representing the versioning scheme used for the software-version
>>>>>>> item, as an integer label with text escape (Section 2).  See
>>>>>>> Section 4.1 for the list of values available for this item. -->
>>>>>>> 
>>>>>>> 
>>>>>>> 16) <!-- [rfced] Section 2.3:  As it appears that "another items" should be "another item", we updated this sentence accordingly.  If this is incorrect, please clarify this text.
>>>>>>> 
>>>>>>> Original:
>>>>>>> *  link (index 4): Provides a means to establish relationship arcs
>>>>>>> between the tag and another items.
>>>>>>> 
>>>>>>> Currently:
>>>>>>> link (index 4):  Provides a means to establish relationship arcs
>>>>>>> between the tag and another item. -->
>>>>>>> 
>>>>>>> 
>>>>>>> 17) <!-- [rfced] Section 2.4:  Does "software version" here refer to the software-version item or to a software version in general?
>>>>>>> 
>>>>>>> Original:
>>>>>>> This ensures that primary and corpus tags  have an identifiable software version. -->
>>>>>>> 
>>>>>>> 
>>>>>>> 18) <!-- [rfced] Section 2.6:  As it appears that this sentence means "... between (1) the entity and (2) this tag or the referenced software component", we removed the comma after "entity" to avoid reader confusion.  If this is incorrect (e.g., the intent is to say "between entities"), please provide clarifying text.
>>>>>>> 
>>>>>>> Original:
>>>>>>> *  role (index 33): An integer or textual value (integer label with
>>>>>>> text escape, see Section 2) representing the relationship(s)
>>>>>>> between the entity, and this tag or the referenced software
>>>>>>> component.
>>>>>>> 
>>>>>>> Currently:
>>>>>>> role (index 33):  An integer or textual value (integer label with
>>>>>>> text escape; see Section 2) representing the relationship(s)
>>>>>>> between the entity and this tag or the referenced software
>>>>>>> component. -->
>>>>>>> 
>>>>>>> 
>>>>>>> 19) <!-- [rfced] Section 2.7:  Please confirm that "-356..65536" and not "-256..65535" is correct here.  We ask because we do not see this range used anywhere else.
>>>>>>> 
>>>>>>> Original:
>>>>>>> $rel /= -356..65536 / text -->
>>>>>>> 
>>>>>>> 
>>>>>>> 20) <!-- [rfced] Section 2.7:  We do not see CBOR mentioned in Section 5.2.  Please confirm that this citation is correct and will be clear to readers.
>>>>>>> 
>>>>>>> Original:
>>>>>>> This specification
>>>>>>> does not define how to resolve an XPATH query in the context of  CBOR, see Section 5.2.
>>>>>>> 
>>>>>>> Possibly (perhaps the intent was to point to the XPath query or
>>>>>>> expression?):
>>>>>>> This specification does not define how to resolve an  XPath expression (Section 5.2) in the context of CBOR. -->
>>>>>>> 
>>>>>>> 
>>>>>>> 21) <!-- [rfced] Section 2.7:  We had trouble following the three instances of "... registry Section 4.3" in this section.  If the suggested text is not correct, please provide text that clarifies the meanings of these citations.
>>>>>>> 
>>>>>>> Please note that in the second and third suggestions we
>>>>>>> (1) suggest different section numbers, as there appear to be some section-number mismatches and (2) changed "COSWID" to "CoSWID".
>>>>>>> 
>>>>>>> Original:
>>>>>>> *  ownership (index 39): An integer or textual value (integer label
>>>>>>> with text escape, see Section 2, for the "Software ID Link
>>>>>>> Ownership Values" registry Section 4.3) used when the "href" item
>>>>>>> references another software component to indicate the degree of
>>>>>>> ownership between the software component referenced by the CoSWID
>>>>>>> tag and the software component referenced by the link.
>>>>>>> ...
>>>>>>> *  rel (index 40): An integer or textual value that (integer label
>>>>>>> with text escape, see Section 2, for the "Software ID Link Link
>>>>>>> Relationship Values" registry Section 4.3) identifies the
>>>>>>> relationship between this CoSWID and the target resource
>>>>>>> identified by the "href" item.
>>>>>>> ...
>>>>>>> *  use (index 42): An integer or textual value (integer label with
>>>>>>> text escape, see Section 2, for the "Software ID Link Link
>>>>>>> Relationship Values" registry Section 4.3) used to determine if
>>>>>>> the referenced software component has to be installed before
>>>>>>> installing the software component identified by the COSWID tag.
>>>>>>> 
>>>>>>> Suggested:
>>>>>>> ownership (index 39):  An integer or textual value (integer label
>>>>>>> with text escape; see Section 2).  See Section 4.3 for the list
>>>>>>> of values available for this item.  This item is used when the
>>>>>>> href item references another software component to indicate the
>>>>>>> degree of ownership between the software component referenced by
>>>>>>> the CoSWID tag and the software component referenced by the link.
>>>>>>> ...
>>>>>>> rel (index 40):  An integer or textual value (integer label with
>>>>>>> text escape; see Section 2).  See Section 4.4 for the list of
>>>>>>> values available for this item.  This item identifies the
>>>>>>> relationship between this CoSWID and the target resource
>>>>>>> identified by the href item.
>>>>>>> ...
>>>>>>> use (index 42):  An integer or textual value (integer label with
>>>>>>> text escape; see Section 2).  See Section 4.5 for the list of
>>>>>>> values available for this item.  This item is used to determine
>>>>>>> if the referenced software component has to be installed before
>>>>>>> installing the software component identified by the CoSWID tag. -->
>>>>>>> 
>>>>>>> 
>>>>>>> 22) <!-- [rfced] Section 2.8:  Should "i.e.," (that is) be "e.g.," (for
>>>>>>> example) here?  In other words are license keys the only applicable category as related to a given software component install, or would serial numbers or product keys also be applicable?
>>>>>>> 
>>>>>>> Original:
>>>>>>> Examples of an entitlement-key might include a  serial number, product key, or license key.  For values that  relate to a given software component install (i.e., license key),  a supplemental tag will typically contain this information. -->
>>>>>>> 
>>>>>>> 
>>>>>>> 23) <!-- [rfced] Section 2.8:  There appears to be a string mismatch for "$$meta-extension" versus "$$software-meta-extension".  Table 1, the CDDL earlier in this section, and Section 2.10 use "$$software-meta-extension".  Which string is correct?
>>>>>>> 
>>>>>>> Original:
>>>>>>> | software-meta-entry | $$software-meta-extension       | Section |
>>>>>>> |                     |                                 | 2.8     |
>>>>>>> ...
>>>>>>> * $$software-meta-extension,
>>>>>>> ...
>>>>>>> *  $$meta-extension: This CDDL socket can be used to extend the
>>>>>>> software-meta-entry group model.  See Section 2.2.
>>>>>>> ...
>>>>>>> * $$software-meta-extension, -->
>>>>>>> 
>>>>>>> 
>>>>>>> 24) <!-- [rfced] Section 2.10:
>>>>>>> 
>>>>>>> a) Please confirm that "64436" is correct here.  We ask because we do not see this value used anywhere else.
>>>>>>> 
>>>>>>> Original:
>>>>>>> $rel /= -256..64436 / text
>>>>>>> 
>>>>>>> b) "already defined earlier" reads oddly.  Should a specific section number be cited here?  If not, would "already defined" or "defined earlier" be sufficient?
>>>>>>> 
>>>>>>> Original:
>>>>>>> ; supplemental=11 ; this is already defined earlier -->
>>>>>>> 
>>>>>>> 
>>>>>>> 25) <!-- [rfced] Section 3:  We had trouble following the meaning of "Multiple of" here.  Does "Multiple of" mean "Multiples of", "Multiple", or something else?  Please clarify.
>>>>>>> 
>>>>>>> Original:
>>>>>>> Note: Multiple of the corpus, patch, and supplemental items can have  values set as "true".  The rules above provide a means to determine  the tag's type in such a case.  For example, a SWID or CoSWID tag for  a patch installer might have both corpus and patch items set to  "true".  In such a case, the tag is a "Corpus Tag".  The tag  installed by this installer would have only the patch item set to  "true", making the installed tag type a "Patch Tag". -->
>>>>>>> 
>>>>>>> 
>>>>>>> 26) <!-- [rfced] Section 4:  We could not follow the meaning of "that are maintained in a registry each".  Does this mean "that are each maintained in separate IANA registries (Section 6)", "that are maintained in several IANA registries (Section 6)", or something else?  If the suggested text is not correct, please clarify.
>>>>>>> 
>>>>>>> Original:
>>>>>>> This section defines a number of kinds of indexed label values that  are maintained in a registry each (Section 6).
>>>>>>> 
>>>>>>> Suggested:
>>>>>>> This section defines a number of kinds of indexed label values that  are maintained in several IANA registries.  See Section 6 for  details. -->
>>>>>>> 
>>>>>>> 
>>>>>>> 27) <!-- [rfced] Table 6:  We had trouble following "another software that" here.  We updated the text.  If this update is incorrect, please clarify this sentence.
>>>>>>> 
>>>>>>> Original:
>>>>>>> | 10    | supersedes        | The link references another           |
>>>>>>> |       |                   | software that this software           |
>>>>>>> |       |                   | replaces.  A patch tag (see           |
>>>>>>> 
>>>>>>> Currently:
>>>>>>> | 10    | supersedes        | The link references other software   |
>>>>>>> |       |                   | (e.g., an older software version)    |
>>>>>>> |       |                   | that this software replaces.  A      | -->
>>>>>>> 
>>>>>>> 
>>>>>>> 28) <!-- [rfced] Section 6.2.1:  Should "uint_8t" be "uint8_t" here?
>>>>>>> We ask because we do not see any instances of "uint_8t" in any RFC.
>>>>>>> However, we see "uint8_t" in RFC 8949.
>>>>>>> 
>>>>>>> Original:
>>>>>>> This allows values -1 to -24 to be expressed as a single  uint_8t in CBOR, and values -25 to -256 to be expressed using an  additional uint_8t in CBOR. -->
>>>>>>> 
>>>>>>> 
>>>>>>> 29) <!-- [rfced] Sections 6.2.4 through 6.2.8:  As it appears that "which" in these sentences refers to the initial registrations derived from names or values defined in [SWID], and not to the registries themselves, we updated the sentences accordingly.  If these updates are incorrect, please provide clarifying text.
>>>>>>> 
>>>>>>> Original:
>>>>>>> Initial registrations for the "Software ID Version Scheme Values"
>>>>>>> registry are provided below, which are derived from the textual  version scheme names defined in [SWID].
>>>>>>> ...
>>>>>>> Initial registrations for the "Software ID Entity Role Values"
>>>>>>> registry are provided below, which are derived from the textual  entity role names defined in [SWID].
>>>>>>> ...
>>>>>>> Initial registrations for the "Software ID Link Ownership Values"
>>>>>>> registry are provided below, which are derived from the textual  entity role names defined in [SWID].
>>>>>>> ...
>>>>>>> Initial registrations for the "Software ID Link Relationship Values"
>>>>>>> registry are provided below, which are derived from the link  relationship values defined in [SWID].
>>>>>>> ...
>>>>>>> Initial registrations for the "Software ID Link Use Values" registry  are provided below, which are derived from the link relationship  values defined in [SWID].
>>>>>>> 
>>>>>>> Currently:
>>>>>>> Initial registrations for the "Software ID Version Scheme Values"
>>>>>>> registry are provided below and are derived from the textual version  scheme names defined in [SWID].
>>>>>>> ...
>>>>>>> Initial registrations for the "Software ID Entity Role Values"
>>>>>>> registry are provided below and are derived from the textual entity  role names defined in [SWID].
>>>>>>> ...
>>>>>>> Initial registrations for the "Software ID Link Ownership Values"
>>>>>>> registry are provided below and are derived from the textual entity  role names defined in [SWID].
>>>>>>> ...
>>>>>>> Initial registrations for the "Software ID Link Relationship Values"
>>>>>>> registry are provided below and are derived from the link  relationship values defined in [SWID].
>>>>>>> ...
>>>>>>> Initial registrations for the "Software ID Link Use Values" registry  are provided below and are derived from the link relationship values  defined in [SWID]. -->
>>>>>>> 
>>>>>>> 
>>>>>>> 30) <!-- [rfced] Section 6.2.4:  Should "version item" here be "software-version item"?  We do not see "version item" used anywhere else in this document.
>>>>>>> 
>>>>>>> Original:
>>>>>>> Designated experts MUST also ensure that newly requested entries  define a value space for the corresponding version item that is  unique from other previously registered entries. -->
>>>>>>> 
>>>>>>> 
>>>>>>> 31) <!-- [rfced] Sections 7 and 8:
>>>>>>> Should "COSE-Sign1-coswid<payload>" and "COSE-Sign-coswid<payload>"
>>>>>>> be "COSE_Sign1-coswid<payload>" and "COSE_Sign-coswid<payload>"
>>>>>>> (i.e., underscores after "COSE" instead of hyphens)?  We ask because we see "COSE_Sign1" and "COSE_Sign" used in the second paragraph of Section 7.
>>>>>>> 
>>>>>>> Original:
>>>>>>> COSE-Sign1-coswid<payload> = [
>>>>>>> ...
>>>>>>> COSE-Sign-coswid<payload> = [
>>>>>>> ...
>>>>>>> signed-coswid-for<payload> = #6.18(COSE-Sign1-coswid<payload>)
>>>>>>> / #6.98(COSE-Sign-coswid<payload>) -->
>>>>>>> 
>>>>>>> 
>>>>>>> 32) <!-- [rfced] Section 7:  Should "signature :" be "signature:" here?
>>>>>>> 
>>>>>>> Original:
>>>>>>> signature : bstr -->
>>>>>>> 
>>>>>>> 
>>>>>>> 33) <!-- [rfced] Section 8:  We had trouble following this sentence.
>>>>>>> If the suggested update is not correct, please provide text that clarifies the meaning of "Consecutively" and "a CoSWID tags".
>>>>>>> 
>>>>>>> Original:
>>>>>>> Consecutively, the CBOR tag for CoSWID tags  defined in Table 21 SHOULD be used in conjunction with CBOR data  items that are a CoSWID tags.
>>>>>>> 
>>>>>>> Suggested:
>>>>>>> Consequently, the CBOR tag defined by this  document (Table 21) for CoSWID tags SHOULD be used in conjunction  with CBOR data items that are CoSWID tags. -->
>>>>>>> 
>>>>>>> 
>>>>>>> 34) <!-- [rfced] Section 8:  "a tagged CoSWID tag" reads oddly.  Please confirm that the text is correct and will be clear to readers (e.g., are any words missing?).
>>>>>>> 
>>>>>>> Original:
>>>>>>> This specification allows for a tagged CoSWID tag to reside in a COSE  envelope that is also tagged with a CoSWID CBOR tag. -->
>>>>>>> 
>>>>>>> 
>>>>>>> 35) <!-- [rfced] Section 9:  To prevent some readers from possibly interpreting "since" as "because", we changed "since it was signed"
>>>>>>> in this sentence to "since the time at which it was signed".  Please let us know any concerns.
>>>>>>> 
>>>>>>> Original:
>>>>>>> A signed CoSWID tag (see Section 7) whose signature has been  validated can be relied upon to be unchanged since it was signed.
>>>>>>> 
>>>>>>> Currently:
>>>>>>> A signed CoSWID tag (see Section 7) whose signature has been  validated can be relied upon to be unchanged since the time at which  it was signed. -->
>>>>>>> 
>>>>>>> 
>>>>>>> 36) <!-- [rfced] Section 9:  Does "including a public key" refer to the certification path or the certificate?
>>>>>>> 
>>>>>>> Original:
>>>>>>> A certification path between a trust anchor and a certificate  including a public key enabling the validation of a tag signature can  realize the assessment of trustworthiness of an authoritative tag.
>>>>>>> 
>>>>>>> Perhaps (certification path that includes):
>>>>>>> A certification path between a trust anchor and a certificate,  including a public key enabling the validation of a tag signature,  can realize the assessment of trustworthiness of an authoritative  tag.
>>>>>>> 
>>>>>>> Or possibly (certificate that includes):
>>>>>>> A certification path between (1) a trust anchor and (2) a certificate  that includes a public key enabling the validation of a tag signature  can realize the assessment of trustworthiness of an authoritative  tag. -->
>>>>>>> 
>>>>>>> 
>>>>>>> 37) <!-- [rfced] Section 9: We had trouble following this sentence.
>>>>>>> Please provide text that clarifies the meaning of "associated corresponding to".
>>>>>>> 
>>>>>>> Original:
>>>>>>> This requires an association between the signature and the  tag's entity item associated corresponding to the software provider. -->
>>>>>>> 
>>>>>>> 
>>>>>>> 38) <!-- [rfced] Section 9:  "controlled to authorized applications and users" reads oddly.  Should "controlled to" be "controlled for" or perhaps "limited to"?  If not, please provide clarifying text.
>>>>>>> 
>>>>>>> Original:
>>>>>>> Access to the collection of an
>>>>>>> endpoint's CoSWID tags needs to be appropriately controlled to  authorized applications and users using an appropriate access control  mechanism. -->
>>>>>>> 
>>>>>>> 
>>>>>>> 39) <!-- [rfced] When accessing the page corresponding to [W3C.REC-css3-mediaqueries-20120619], we got a red popup saying "This version is outdated!"  Because the citations in this document are general in nature, we updated the citation string and reference listing as follows.  Please let us know any concerns.
>>>>>>> 
>>>>>>> Original:
>>>>>>> [W3C.REC-css3-mediaqueries-20120619]
>>>>>>>      Rivoal, F., Ed., "Media Queries", W3C REC REC-css3-
>>>>>>>      mediaqueries-20120619, W3C REC-css3-mediaqueries-20120619,
>>>>>>>      19 June 2012, <https://www.w3.org/TR/2012/REC-css3-
>>>>>>>      mediaqueries-20120619/>.
>>>>>>> 
>>>>>>> Currently:
>>>>>>> [W3C.REC-mediaqueries-3-20220405]
>>>>>>>      Rivoal, F., Ed., "Media Queries Level 3", W3C
>>>>>>>      Recommendation REC-mediaqueries-3-20220405, 5 April 2022,
>>>>>>>      <https://www.w3.org/TR/mediaqueries-3/>. -->
>>>>>>> 
>>>>>>> 
>>>>>>> 40) <!-- [rfced] Please review the "Inclusive Language" portion of the online Style Guide at <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>,
>>>>>>> and let us know if any changes are needed.
>>>>>>> 
>>>>>>> For example, please consider whether the following should be updated:
>>>>>>> 
>>>>>>> whitespace -->
>>>>>>> 
>>>>>>> 
>>>>>>> 41) <!-- [rfced] Please let us know if any changes are needed for the
>>>>>>> following:
>>>>>>> 
>>>>>>> a) The following terms were used inconsistently in this document.
>>>>>>> We chose to use the latter forms.  Please let us know any objections.
>>>>>>> 
>>>>>>> URI-scheme (titles of Sections 6.6.1 and 6.6.2) / URI Scheme
>>>>>>> 
>>>>>>> Version Scheme Name / version scheme name (in running text)
>>>>>>> 
>>>>>>> XPATH / XPath (per usage elsewhere in this document and per W3C)
>>>>>>> 
>>>>>>> b) The following terms appear to be used inconsistently in this document.  Please let us know which form is preferred.
>>>>>>> 
>>>>>>> private use / Private Use (e.g., "for private use", "for Private Use")
>>>>>>> 
>>>>>>> XML schema / XML Schema
>>>>>>> 
>>>>>>> c) The following terms appear to be used inconsistently in this document and the companion documents. Please let us know which form is preferred.
>>>>>>> 
>>>>>>> indices / indexes
>>>>>>> 
>>>>>>> reference integrity measurements (RIM) / reference measurements (RIMs) /
>>>>>>> Reference Integrity Manifests (RIMs)
>>>>>>> 
>>>>>>> d) Quoting of item names was inconsistent.  For example:
>>>>>>> 
>>>>>>> href item vs. "href" item
>>>>>>> role item vs. "role" item
>>>>>>> 
>>>>>>> We removed the quotes, as item names were mostly unquoted.
>>>>>>> Please let us know any objections. -->
>>>>>>> 
>>>>>>> 
>>>>>>> Thank you.
>>>>>>> 
>>>>>>> RFC Editor/lb/kc
>>>>>>> 
>>>>>>> 
>>>>>>> On Apr 14, 2023, at 2:41 PM, [e-mail] wrote:
>>>>>>> 
>>>>>>> *****IMPORTANT*****
>>>>>>> 
>>>>>>> Updated 2023/04/14
>>>>>>> 
>>>>>>> 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/rfc9393.xml
>>>>>>> https://www.rfc-editor.org/authors/rfc9393.html
>>>>>>> https://www.rfc-editor.org/authors/rfc9393.pdf
>>>>>>> https://www.rfc-editor.org/authors/rfc9393.txt
>>>>>>> 
>>>>>>> Diff file of the text:
>>>>>>> https://www.rfc-editor.org/authors/rfc9393-diff.html
>>>>>>> https://www.rfc-editor.org/authors/rfc9393-rfcdiff.html (side by side)
>>>>>>> 
>>>>>>> Diff of the XML:
>>>>>>> https://www.rfc-editor.org/authors/rfc9393-xmldiff1.html
>>>>>>> 
>>>>>>> XMLv3 file that is a best effort to capture v3-related format updates
>>>>>>> only:
>>>>>>> https://www.rfc-editor.org/authors/rfc9393.form.xml
>>>>>>> 
>>>>>>> 
>>>>>>> Tracking progress
>>>>>>> -----------------
>>>>>>> 
>>>>>>> The details of the AUTH48 status of your document are here:
>>>>>>> https://www.rfc-editor.org/auth48/rfc9393
>>>>>>> 
>>>>>>> Please let us know if you have any questions.
>>>>>>> 
>>>>>>> Thank you for your cooperation,
>>>>>>> 
>>>>>>> RFC Editor
>>>>>>> 
>>>>>>> --------------------------------------
>>>>>>> RFC9393 (draft-ietf-sacm-coswid-24)
>>>>>>> 
>>>>>>> Title            : Concise Software Identification Tags
>>>>>>> Author(s)        : H. Birkholz, J. Fitzgerald-McKay, C. Schmidt, D. Waltermire
>>>>>>> WG Chair(s)      : Karen O'Donoghue, Christopher Inacio
>>>>>>> 
>>>>>>> Area Director(s) : Roman Danyliw, Paul Wouters
>>>>>>> 
>>>>>>> 
>