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

[Amanda Baber via RT <[e-mail]>]

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
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>
> >