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

[Lynne Bartholomew <[e-mail]>]

Hi, Amanda*.

Apologies for the "RFC 9393"s; understood that those should wait until after this document is published.  We also see that "this document" is not sufficiently clear and that "RFC-ietf-sacm-coswid-24, or" instead of "or" is needed.

* A request:  Can we please change "Software-IDs" to "Software IDs" on <https://www.iana.org/assignments/uri-schemes/prov/swid> and <https://www.iana.org/assignments/uri-schemes/prov/swidpath> now, so that these particular updates don't fall through the cracks later?

The other updates look good, and thank you for those!

RFC Editor/lb


> On Jun 22, 2023, at 4:07 PM, Amanda Baber via RT <[e-mail]> wrote:
> 
> Hi,
> 
> We've made most of these changes, but had to temporarily skip or adjust others. Please see below.
> 
>> OLD:
>> Interoperability considerations: Applications MAY ignore any key
>> value pairs that they do not understand.  This allows backwards
>> compatible extensions to this specification.
>> 
>> Applications that use this media type: The type is used by software
>> asset management systems, vulnerability assessment systems, and in
>> applications that use remote integrity verification.
>> 
>> Magic number(s): if tagged, first five bytes in hex: da 53 57 49 44
>> (see Section 8 in RFC-ietf-sacm-coswid-24)
>> 
>> Macintosh Universal Type Identifier code: org.ietf.coswid conforms to
>> public.data
>> 
>> Restrictions on usage: None
>> 
>> NEW:
>> Interoperability considerations:  Applications MAY ignore any key
>> value pairs that they do not understand.  This allows backwards-
>> compatible extensions to this specification.
>> 
>> Applications that use this media type:  The type is used by software
>> asset management systems and vulnerability assessment systems and
>> is used in applications that use remote integrity verification.
>> 
>> Magic number(s):  If tagged, the first five bytes in hex: da 53 57
>> 49 44 (see Section 8 of RFC-ietf-sacm-coswid-24).
>> 
>> Macintosh Universal Type Identifier code:  org.ietf.coswid
>> conforms to public.data.
>> 
>> Restrictions on usage: none
> 
> These changes are complete:
> 
> https://www.iana.org/assignments/media-types/application/swid+cbor
> 
>> = = = = = = = =
>> 
>> Per updates to Section 6.6.1, please update the following on
>> <https://www.iana.org/assignments/uri-schemes/prov/swid>:
>> 
>> OLD:
>> Applications/protocols that use this scheme name: Applications that
>> require Software-IDs (SWIDs) or Concise Software-IDs (CoSWIDs); see
>> Section 5.1 of RFC-ietf-sacm-coswid-24.
>> 
>> Reference: Section 5.1 in RFC-ietf-sacm-coswid-24
>> 
>> NEW:
>> Applications/protocols that use this scheme name:  Applications that
>> require Software IDs (SWIDs) or Concise Software IDs (CoSWIDs);
>> see Section 5.1 of RFC 9393.
>> 
>> Reference:  Section 5.1 of RFC 9393
> 
> We were unable to make these reference changes. Our policy is to wait to replace draft strings with RFC numbers until the RFC has been published.
> 
>> Also, please update the following on
>> <https://www.iana.org/assignments/uri-schemes/expert-notes/swid-
>> expert-notes>:
>> 
>> OLD:
>> This scheme has been documented by an IETF working group, and is
>> mentioned in an IETF standard specification. But as it describes a
>> locally scoped, limited purpose, form of identification, it does not
>> fully meet the requirements for permanent registration.
>> 
>> As long as the specification (RFC-ietf-sacm-coswid-24, or successors)
>> that describes this scheme is a current IETF specification, this
>> scheme should be considered to be "in use" and not considered for
>> removal from the registry.
>> 
>> NEW:
>> Note: This scheme has been documented by an IETF working group
>> and is mentioned in an IETF Standard specification.  However,
>> as it describes a locally scoped, limited-purpose form of
>> identification, it does not fully meet the requirements for
>> permanent registration.
>> 
>> As long as this specification (or any successors that describe
>> this scheme) is a current IETF specification, this scheme
>> should be considered to be "in use" and not considered for
>> removal from the registry.
> 
> We updated this note, but because there is no other indication as to the identity of "this document" at https://www.iana.org/assignments/uri-schemes/expert-notes/swid-expert-notes, replaced "(or any successors that describe this scheme)" with "(RFC-ietf-sacm-coswid-24, or any successors that describe this scheme)." 
> 
>> = = = = = = = =
>> 
>> Per updates to Section 6.6.2, please update the following on
>> <https://www.iana.org/assignments/uri-schemes/prov/swidpath>:
>> 
>> OLD:
>> Applications/protocols that use this scheme name: Applications that
>> require Software-IDs (SWIDs) or Concise Software-IDs (CoSWIDs); see
>> Section 5.2 of RFC-ietf-sacm-coswid-24.
>> 
>> Reference: Section 5.2 in RFC-ietf-sacm-coswid-24
>> 
>> NEW:
>> Applications/protocols that use this scheme name:  Applications that
>> require Software IDs (SWIDs) or Concise Software IDs (CoSWIDs);
>> see Section 5.2 of RFC 9393.
>> 
>> Reference:  Section 5.2 of RFC 9393
> 
> We can't make these reference changes until the RFC has been published.
> 
>> Also, please update the following on
>> <https://www.iana.org/assignments/uri-schemes/expert-notes/swidpath-
>> expert-notes>:
>> 
>> OLD:
>> This scheme has been documented by an IETF working group, and is
>> mentioned in an IETF standard specification. But as it describes a
>> locally scoped, limited purpose, form of identification, it does not
>> fully meet the requirements for permanent registration.
>> 
>> As long as the specification (RFC-ietf-sacm-coswid-24, or successors)
>> that describes this scheme is a current IETF specification, this
>> scheme should be considered to be "in use" and not considered for
>> removal from the registry.
>> 
>> NEW:
>> Note: This scheme has been documented by an IETF working group
>> and is mentioned in an IETF Standard specification.  However,
>> as it describes a locally scoped, limited-purpose form of
>> identification, it does not fully meet the requirements for
>> permanent registration.
>> 
>> As long as this specification (or any successors that describe
>> this scheme) is a current IETF specification, this scheme
>> should be considered to be "in use" and not considered for
>> removal from the registry.
> 
> We updated this note, but as above, replaced "(or any successors that describe this scheme)" with "(RFC-ietf-sacm-coswid-24, or any successors that describe this scheme)." See
> 
> https://www.iana.org/assignments/uri-schemes/expert-notes/swidpath-expert-notes
> 
> thanks,
> 
> Amanda Baber
> IANA Operations Manager
> 
>> Thank you!
>> 
>> RFC Editor/lb
>> 
>>> On Jun 21, 2023, at 1:31 PM, Lynne Bartholomew
>>> <[e-mail]> wrote:
>>> 
>>> Hi, Roman.  We have noted your approval:
>>> 
>>> https://www.rfc-editor.org/auth48/rfc9393
>>> 
>>> We will email IANA shortly and ask them to make some updates so that
>>> relevant information on their site matches the corresponding entries
>>> in this document.  After those updates are completed, we will prepare
>>> this document for publication.
>>> 
>>> Thank you!
>>> 
>>> RFC Editor/lb
>>> 
>>>> On Jun 21, 2023, at 8:39 AM, Roman Danyliw <[e-mail]> wrote:
>>>> 
>>>> Hi!
>>>> 
>>>> Approved.  Thanks for all of the work here.
>>>> 
>>>> Thanks,
>>>> Roman
>>>> 
>>>>> -----Original Message-----
>>>>> From: Lynne Bartholomew <[e-mail]>
>>>>> Sent: Friday, June 16, 2023 2:57 PM
>>>>> To: Roman Danyliw <[e-mail]>; [e-mail]
>>>>> Cc: Waltermire, David A. (Fed) <[e-mail]>;
>>>>> [e-mail]; [e-mail]; Schmidt,
>>>>> Charles M.
>>>>> <[e-mail]>; [e-mail]; sacm-
>>>>> [e-mail]; Chris
>>>>> Inacio <[e-mail]>; [e-mail]
>>>>> Subject: *[AD] Re: AUTH48: RFC-to-be 9393 <draft-ietf-sacm-coswid-
>>>>> 24> for
>>>>> your review
>>>>> 
>>>>> Hi, Roman.
>>>>> 
>>>>> A reminder that the question listed below is still pending.  Please
>>>>> advise.
>>>>> 
>>>>> The AUTH48 status page is here:
>>>>> 
>>>>> https://www.rfc-editor.org/auth48/rfc9393
>>>>> 
>>>>> Thank you!
>>>>> 
>>>>> RFC Editor/lb
>>>>> 
>>>>>> On Jun 8, 2023, at 8:38 AM, Lynne Bartholomew
>>>>>> <[e-mail]>
>>>>> wrote:
>>>>>> 
>>>>>> Hi, Roman.
>>>>>> 
>>>>>> Please note that this question for you is still pending:
>>>>>> 
>>>>>> <!-- [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. -->
>>>>>> 
>>>>>> The latest files are posted here (with month updated to June):
>>>>>> 
>>>>>> 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
>>>>>> 
>>>>>> The AUTH48 status page is here:
>>>>>> 
>>>>>> https://www.rfc-editor.org/auth48/rfc9393
>>>>>> 
>>>>>> Thank you!
>>>>>> 
>>>>>> RFC Editor/lb
>>>>>> 
>>>>>>> On Jun 8, 2023, at 8:29 AM, Lynne Bartholomew
>>>>> <[e-mail]> wrote:
>>>>>>> 
>>>>>>> Hi, Dave.  No worries; thank you for the email.
>>>>>>> 
>>>>>>> We have noted your approval on the AUTH48 status page:
>>>>>>> 
>>>>>>> https://www.rfc-editor.org/auth48/rfc9393
>>>>>>> 
>>>>>>> Thanks again!
>>>>>>> 
>>>>>>> RFC Editor/lb
>>>>>>> 
>>>>>>>> On Jun 6, 2023, at 7:23 PM, Waltermire, David A. (Fed)
>>>>> <[e-mail]> wrote:
>>>>>>>> 
>>>>>>>> Lynne,
>>>>>>>> 
>>>>>>>> Sorry for the delay. I approve. Thanks.
>>>>>>>> 
>>>>>>>> Dave
>>>>>>>> 
>>>>>>>> -----Original Message-----
>>>>>>>> From: Lynne Bartholomew <[e-mail]>
>>>>>>>> Sent: Friday, June 2, 2023 11:27 AM
>>>>>>>> To: [e-mail]; [e-mail]
>>>>>>>> Cc: Schmidt, Charles M. <[e-mail]>; rfc-editor@rfc-
>>>>> editor.org; Waltermire, David A. (Fed) <[e-mail]>;
>>>>> sacm-
>>>>> [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, 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]" <sacm-
>>>>> [e-mail]>,
>>>>> "[e-mail]" <[e-mail]>, "Inacio,
>>>>> Christopher"
>>>>> <[e-mail]>, "[e-mail]" <[e-mail]>,
>>>>> "auth48archive@rfc-
>>>>> editor.org" <[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]; sacm-
>>>>> [e-mail]; Inacio,
>>>>> Christopher <[e-mail]>; [e-mail]; auth48archive@rfc-
>>>>> editor.org
>>>>>>>>> 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]>; sacm-
>>>>> [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]>; sacm-
>>>>> [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]>; sacm-
>>>>> [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]>; sacm-
>>>>> [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]>; sacm-
>>>>> [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] <rfc-editor@rfc-
>>>>>>>>>>>>>>> editor.org>
>>>>>>>>>>>>>>> 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]; sacm-
>>>>> [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
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>