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

[Roman Danyliw <[e-mail]>]

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]; [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]" <[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]; [e-mail]; Inacio,
> Christopher <[e-mail]>; [e-mail]; [e-mail]
> >>>> Subject: Re: [EXT] [AD] Re: AUTH48: RFC-to-be 9393 <draft-ietf-sacm-
> coswid-24> for your review
> >>>>
> >>>> Hi, Charles.
> >>>>
> >>>> We have made further updates per your notes below.
> >>>>
> >>>> The latest files are posted here:
> >>>>
> >>>> https://www.rfc-editor.org/authors/rfc9393.txt
> >>>> https://www.rfc-editor.org/authors/rfc9393.pdf
> >>>> https://www.rfc-editor.org/authors/rfc9393.html
> >>>> https://www.rfc-editor.org/authors/rfc9393.xml
> >>>> https://www.rfc-editor.org/authors/rfc9393-diff.html
> >>>> https://www.rfc-editor.org/authors/rfc9393-rfcdiff.html
> >>>> https://www.rfc-editor.org/authors/rfc9393-auth48diff.html
> >>>> https://www.rfc-editor.org/authors/rfc9393-lastdiff.html
> >>>> https://www.rfc-editor.org/authors/rfc9393-lastrfcdiff.html
> >>>>
> >>>> https://www.rfc-editor.org/authors/rfc9393-xmldiff1.html
> >>>> https://www.rfc-editor.org/authors/rfc9393-xmldiff2.html
> >>>>
> >>>> Thank you!
> >>>>
> >>>> RFC Editor/lb
> >>>>
> >>>>> On May 25, 2023, at 12:48 PM, Charles M Schmidt
> <[e-mail]> wrote:
> >>>>>
> >>>>> Hello Lynne,
> >>>>>
> >>>>> Thank you for providing the updated drafts. The reordering looks great.
> >>>>>
> >>>>> Regarding some of your other comments from earlier, we identified a
> few editorial tweaks we would like to make to improve clarity.
> >>>>>
> >>>>> Section 2.9.1 - clarify the relationship between hash and thumbprint
> >>>>> OLD:
> >>>>> CoSWID adds explicit support for the representation of hash entries
> using algorithms that are
> >>>>> registered in the IANA "Named Information Hash Algorithm Registry"
> [IANA.named-information]
> >>>>> using the hash member (index 7) and the corresponding hash-entry type
> >>>>>
> >>>>> NEW:
> >>>>> CoSWID adds explicit support for the representation of hash entries
> using algorithms that are
> >>>>> registered in the IANA "Named Information Hash Algorithm Registry"
> [IANA.named-information].
> >>>>> This array is used by both the hash (index 7) and thumbprint (index 34)
> values.
> >>>>>
> >>>>> Section 2.9.2 - revise description of the location element
> >>>>> OLD:
> >>>>> location (index 23): The filesystem path where a file is expected to be
> located when installed or
> >>>>> copied. The location MUST be either relative to the location of the
> parent directory item
> >>>>> (preferred) or relative to the location of the CoSWID tag (as indicated in
> the location value in
> >>>>> the evidence entry map) if no parent is defined. The location MUST NOT
> include a file's name,
> >>>>> which is provided by the fs-name item.
> >>>>>
> >>>>> NEW:
> >>>>> location (index 23): The filesystem path where a file is expected to be
> located when installed or
> >>>>> copied. The location MUST either be an absolute path, or a
> >>>>> path relative to the path value included in the parent directory item
> >>>>> (preferred), or a path relative to the location of the CoSWID tag if no
> >>>>> parent is defined. The location MUST NOT include a file's name,
> >>>>> which is provided by the fs-name item.
> >>>>>
> >>>>> Section 2.9.2 - Add hash = 7 to the code:
> >>>>> OLD:
> >>>>> resource-entry = {
> >>>>> type => text,
> >>>>> * $$resource-extension,
> >>>>> global-attributes,
> >>>>> }
> >>>>> directory = 16
> >>>>> file = 17
> >>>>> process = 18
> >>>>> resource = 19
> >>>>>
> >>>>> NEW:
> >>>>> resource-entry = {
> >>>>> type => text,
> >>>>> * $$resource-extension,
> >>>>> global-attributes,
> >>>>> }
> >>>>> hash = 7
> >>>>> directory = 16
> >>>>> file = 17
> >>>>> process = 18
> >>>>> resource = 19
> >>>>>
> >>>>> Section 2.9.2 - Update the description of the hash item
> >>>>> OLD:
> >>>>> hash (index 7): A hash of the file as described in Section 2.9.1.
> >>>>>
> >>>>> NEW:
> >>>>> hash (index 7): Value that provides a hash of a file. This item provides an
> >>>>> integrity measurement with respect to a specific file. See Section 2.9.1
> >>>>> for more details on the use of the hash-entry data structure.
> >>>>>
> >>>>> Section 2.9.4 - clarify location description by acknowledging previous
> description and the different use in this location
> >>>>> OLD:
> >>>>> location (index 23): The absolute file path of the location of the CoSWID
> tag generated as
> >>>>> evidence. (Location values in filesystem-item instances in the payload
> can be expressed
> >>>>> relative to this location.)
> >>>>>
> >>>>> NEW:
> >>>>> location (index 23): The filesystem path of the location of the CoSWID
> tag generated as
> >>>>> evidence. This path is always an absolute file path (unlike
> >>>>> the value of a location item found within a filesystem-item described
> >>>>> in Section 2.9.2, which can be either a relative path or an absolute path).
> >>>>>
> >>>>> Please let us know if you have any questions or concerns about these
> changes. I believe the remaining questions you had are addressed by the
> clarification that descriptions are not being moved across sections, but just
> being re-ordered within them.
> >>>>>
> >>>>> Thanks a bunch,
> >>>>> Charles
> >>>>>
> >>>>> -----Original Message-----
> >>>>> From: Lynne Bartholomew <[e-mail]>
> >>>>> Sent: Wednesday, May 24, 2023 5:46 PM
> >>>>> To: Charles M Schmidt <[e-mail]>
> >>>>> Cc: [e-mail]; [e-mail];
> [e-mail]; Waltermire, David <[e-mail]>; 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] <[e-mail]>
> >>>>>>>>>> Sent: Friday, April 14, 2023 4:46 PM
> >>>>>>>>>> To: [e-mail]; [e-mail];
> Charles M Schmidt <[e-mail]>; Waltermire, David
> <[e-mail]>
> >>>>>>>>>> Cc: [e-mail]; [e-mail]; 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
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>
> >>>
> >>
> >>
> >>
> >>
> >
> >
> >
> >
>