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.  No worries, and many thanks for fixing!

RFC Editor/lb

> On Jun 23, 2023, at 10:52 AM, Amanda Baber via RT <[e-mail]> wrote:
> 
> Hi,
> 
>> 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?
> 
> Sorry, these changes are complete now!
> 
> https://www.iana.org/assignments/uri-schemes/prov/swid
> 
> https://www.iana.org/assignments/uri-schemes/prov/swidpath
> 
> thanks,
> Amanda
> 
>> 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 <iana-
>>> [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
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>> 
>