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

> Apologies for the "RFC 9393"s; understood that those should wait until
> after this document is published.  We also see that "this document" is
> not sufficiently clear and that "RFC-ietf-sacm-coswid-24, or" instead
> of "or" is needed.
> 
> * A request:  Can we please change "Software-IDs" to "Software IDs" on
> <https://www.iana.org/assignments/uri-schemes/prov/swid> and
> <https://www.iana.org/assignments/uri-schemes/prov/swidpath> now, so
> that these particular updates don't fall through the cracks later?

Sorry, these changes are complete now!

https://www.iana.org/assignments/uri-schemes/prov/swid

https://www.iana.org/assignments/uri-schemes/prov/swidpath

thanks,
Amanda

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