Subject: Re: [sacm] WGLC for draft-ietf-sacm-coswid

From: "Nelson, Alexander J. (Fed)" <[email-masked]>
Date: Wed, 3 Jul 2019 17:07:08 +0000

Hello all,

I am a colleague of Dave's, and am working at NIST to assist with SWID adoption.  I have reviewed this draft for CoSWID, and found a few helpful notes for my own implementation efforts, so I am glad to have been asked for input.

I find this draft to be nearly ready for publication.  There are a few minor editorial issues that should be resolved before publication, listed at the end of this message.  I also found I had a few questions and possible discrepancy identifications, listed first.

Questions:

* Before I started reading the document, I thought that CoSWID would be a losslessly-translatable representation of SWID data, between XML and CBOR.  >From Section 2's third paragraph, this is stated to not be a goal feature.  (In case it isn't clear, I don't object to this.)  Is it at least possible to translate from one format to the other, not necessarily bilaterally, and perhaps under certain conditions like "if there are no extension elements or attributes, SWID XML can be mechanically translated to CoSWID"?  From my reading, it looks like that example statement I just wrote would hold.

* Section 2.2, the "software-name (index 1)" text describes what I think is the first potential spot for non-ASCII text to be entered into CoSWID data, in the case of vendors that produce non-English data.  I didn't see in this document any requirements imposed for character encodings.  SWID imposes UTF-8 as an encoding (per NISTIR 8060, Section 4.3).  Could this document include a reminder statement on character encodings being required to be UTF-8?
  - This might also apply in Section 5.2.1, the penultimate bullet describing registered names' syntax requirements.

* Section 6's 2nd paragraph describes a requirement of authoritative tags being signed by the software provider that is also the originator.  Forgive me if I'm misremembering, but I did not think that signing was a requirement for defining a tag to be authoritative.  NISTIR 8060, Section 3.2, quotes the SWID specification's Section 6.1.10 to say that "Signatures are not a mandatory part of the software identification standard...".  Further, NISTIR 8060, Section 4.2, provides a scoped-to-that-document definition of "authoritative tag creator" that does not describe signing.  So, it looks to me like Section 6 imposes a stronger requirement for an "authoritative" CoSWID tag than an XML-based SWID tag.

Editorial issues:

* Section 1 makes reference to "CBOR," but the first instance of the acronym expansion and citation is in the first sentence of Section 1.2.  It may be better to move that expansion and citation to Section 1.

* Figure 1's "x" annotations aren't directly explained, and could be interpreted to mean removal of the tag at that stage.  From the following bulleted narrative, it instead appears to mean the tag can be removed or replaced.  A sentence in the figure's caption would help to prevent this conclusion.  Though, if the reader is assumed to have the patience to wait for a page, then there's no problem.

* Suggested grammar fix, section 2:

    s/and stop point are not needed saving bytes/and stop point are not needed, saving bytes/

* Request for grammar adjustment, Section 2.1:  """... that are typically stored in the "any attribute" of an ISO-19770-2:2015 in XML representation."""  Does this need the following substitution?

    s/2015 in XML/2015 element in XML/

* Section 2.2, I'm curious - what happened to the mapping of 7?  No editorial action needed, the skip just caught my eye.

* Section 2.2, typo: "The value of an version-scheme ..."

* Section 2.2, typesetting error: The three bullets following "The value of an version-scheme item MUST be one of the following" appear to be set at an incorrect bullet level.  Elsewhere in the document, these sub-lists use asterisks as bullets instead of empty circles.  It appears these three bullets should be asterisks, not empty circles.

* Section 2.3, bullet 2 ("""If the patch item is set to "true", the tag SHOULD..."""): Would it be beneficial here to note the associated schemes for link hrefs?  This could be a forward reference to Section 2.6.

* Section 2.7, bullet "description (index 46)": Is it permitted to have a description be multiple lines?  I don't know if CBOR supports this.

* Section 2.7, typo: "For examplem, this ..."

* Section 2.7, bullet "unspsc-code":  Non-blocking issue, a matter of web reference hygiene.  May this URL be provided with the "https" protocol instead of the "http" protocol?  (Bibliography entries refer to web resources with the "https" protocol.)

* Section 2.8.8, bullet "path-elements (index 26)", typo: "a heirarchy".

* Table 3, typo: "e.g.,1.2.3, ..." (missing space character)

* Section 5.2.1, typo: "a new a new"

* Section 6, paragraph 2: It may be beneficial to provide a reference to RFC 8152 near the mention of signing CoSWID tags.

--Alex

On Jun 27, 2019, at 4:36 PM, Karen O'Donoghue <[email-masked]<mailto:[email-masked]>> wrote:

Folks,

As discussed at our virtual interim on Tuesday, this begins a three week working group last call for:

Concise Software Identification Tags
https://datatracker.ietf.org/doc/draft-ietf-sacm-coswid/<https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-sacm-coswid%2F&data=02%7C01%7Calexander.nelson%40nist.gov%7C22e5bc09733f48ffbd6d08d6fb3f246a%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C1%7C636972645963180804&sdata=740Bq0AAyUgFS%2Fqhj6N0zCKYprCQisIfy%2BVMKdIE4RQ%3D&reserved=0>

Please reply to this email thread with an indication that you have read the document, any comments you may have, and your assessment of whether or not it is ready to proceed to publication.

DEADLINE: Please reply by Friday 19 July 2019.

Thanks!
Karen and Chris
_______________________________________________
sacm mailing list
[email-masked]<mailto:[email-masked]>
https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsacm&amp;data=02%7C01%7Calexander.nelson%40nist.gov%7C22e5bc09733f48ffbd6d08d6fb3f246a%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636972645963210782&amp;sdata=QgjyLJMaeZUPWnvQg0H2fzqe%2BqrcHZX4KzooJ7KuuPE%3D&amp;reserved=0

---

From: "Waltermire, David A. (Fed)" <[email-masked]>
Date: Wed, 3 Jul 2019 17:33:15 +0000

Thanks for the feedback Alex. I'll fix these issue at the end of the WGLC along with any other comments that come up.

Regards,
Dave

From: sacm <[email-masked]> On Behalf Of Nelson, Alexander J. (Fed)
Sent: Wednesday, July 3, 2019 1:07 PM
To: [email-masked]
Subject: Re: [sacm] WGLC for draft-ietf-sacm-coswid

Hello all,

Questions:

Editorial issues:

* Section 2.2, typo: "The value of an version-scheme ...."

--Alex

Folks,

Concise Software Identification Tags
https://datatracker.ietf.org/doc/draft-ietf-sacm-coswid/<https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-sacm-coswid%2F&data=02%7C01%7Cdavid.waltermire%40nist.gov%7C91c6b28941ce4a772c3c08d6ffd8f9e3%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C1%7C636977704712452256&sdata=PAS8N3br%2FthOhPonKJzuWUlIsn9bQvqSZ%2F6hbE3%2FhDU%3D&reserved=0>

Thanks!
Karen and Chris
_______________________________________________
sacm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sacm

---

From: Ira McDonald <[email-masked]>
Date: Thu, 4 Jul 2019 04:48:07 -0400

Hi Dave,

To Alex's point about UTF-8 usage, I recommend requiring conformance to
RFC 5198 Unicode Format for Network Interchange, to remove ambiguity
and ensure normalization of text.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Co-Chair - TCG Trusted Mobility Solutions WG
Co-Chair - TCG Metadata Access Protocol SG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto: [email-masked]
PO Box 221  Grand Marais, MI 49839  906-494-2434

On Wed, Jul 3, 2019 at 1:33 PM Waltermire, David A. (Fed) <david.waltermire=
[email-masked]> wrote:

> Thanks for the feedback Alex. I’ll fix these issue at the end of the WGLC
> along with any other comments that come up.
>
>
>
> Regards,
>
> Dave
>
>
>
> *From:* sacm <[email-masked]> *On Behalf Of * Nelson, Alexander J.
> (Fed)
> *Sent:* Wednesday, July 3, 2019 1:07 PM
> *To:* [email-masked]
> *Subject:* Re: [sacm] WGLC for draft-ietf-sacm-coswid
>
>
>
> Hello all,
>
>
>
> I am a colleague of Dave's, and am working at NIST to assist with SWID
> adoption.  I have reviewed this draft for CoSWID, and found a few helpful
> notes for my own implementation efforts, so I am glad to have been asked
> for input.
>
>
>
> I find this draft to be nearly ready for publication..  There are a few
> minor editorial issues that should be resolved before publication, listed
> at the end of this message.  I also found I had a few questions and
> possible discrepancy identifications, listed first.
>
>
>
>
>
> Questions:
>
>
>
> * Before I started reading the document, I thought that CoSWID would be a
> losslessly-translatable representation of SWID data, between XML and CBOR.
> From Section 2's third paragraph, this is stated to not be a goal feature.
>  (In case it isn't clear, I don't object to this.)  Is it at least possible
> to translate from one format to the other, not necessarily bilaterally, and
> perhaps under certain conditions like "if there are no extension elements
> or attributes, SWID XML can be mechanically translated to CoSWID"?  From my
> reading, it looks like that example statement I just wrote would hold.
>
>
>
> * Section 2.2, the "software-name (index 1)" text describes what I think
> is the first potential spot for non-ASCII text to be entered into CoSWID
> data, in the case of vendors that produce non-English data.  I didn't see
> in this document any requirements imposed for character encodings.  SWID
> imposes UTF-8 as an encoding (per NISTIR 8060, Section 4.3).  Could this
> document include a reminder statement on character encodings being required
> to be UTF-8?
>
>   - This might also apply in Section 5.2.1, the penultimate bullet
> describing registered names' syntax requirements.
>
>
>
> * Section 6's 2nd paragraph describes a requirement of authoritative tags
> being signed by the software provider that is also the originator.  Forgive
> me if I'm misremembering, but I did not think that signing was a
> requirement for defining a tag to be authoritative.  NISTIR 8060, Section
> 3.2, quotes the SWID specification's Section 6.1.10 to say that "Signatures
> are not a mandatory part of the software identification standard...".
> Further, NISTIR 8060, Section 4.2, provides a scoped-to-that-document
> definition of "authoritative tag creator" that does not describe signing.
> So, it looks to me like Section 6 imposes a stronger requirement for an
> "authoritative" CoSWID tag than an XML-based SWID tag.
>
>
>
>
>
> Editorial issues:
>
>
>
> * Section 1 makes reference to "CBOR," but the first instance of the
> acronym expansion and citation is in the first sentence of Section 1.2.  It
> may be better to move that expansion and citation to Section 1.
>
>
>
> * Figure 1's "x" annotations aren't directly explained, and could be
> interpreted to mean removal of the tag at that stage.  From the following
> bulleted narrative, it instead appears to mean the tag can be removed or
> replaced.  A sentence in the figure's caption would help to prevent this
> conclusion.  Though, if the reader is assumed to have the patience to wait
> for a page, then there's no problem.
>
>
>
> * Request for grammar adjustment, Section 2.1:  """... that are typically
> stored in the "any attribute" of an ISO-19770-2:2015 in XML
> representation."""  Does this need the following substitution?
>
>
>
> * Section 2.2, I'm curious - what happened to the mapping of 7?  No
> editorial action needed, the skip just caught my eye.
>
>
>
> * Section 2.2, typesetting error: The three bullets following "The value
> of an version-scheme item MUST be one of the following" appear to be set at
> an incorrect bullet level.  Elsewhere in the document, these sub-lists use
> asterisks as bullets instead of empty circles.  It appears these three
> bullets should be asterisks, not empty circles.
>
>
>
> * Section 2.3, bullet 2 ("""If the patch item is set to "true", the tag
> SHOULD..."""): Would it be beneficial here to note the associated schemes
> for link hrefs?  This could be a forward reference to Section 2.6.
>
>
>
> * Section 2.7, bullet "description (index 46)": Is it permitted to have a
> description be multiple lines?  I don't know if CBOR supports this.
>
>
>
> * Section 2.7, bullet "unspsc-code":  Non-blocking issue, a matter of web
> reference hygiene.  May this URL be provided with the "https" protocol
> instead of the "http" protocol?  (Bibliography entries refer to web
> resources with the "https" protocol.)
>
>
>
> * Section 6, paragraph 2: It may be beneficial to provide a reference to
> RFC 8152 near the mention of signing CoSWID tags.
>
>
>
>
>
> --Alex
>
>
>
>
>
> On Jun 27, 2019, at 4:36 PM, Karen O'Donoghue <[email-masked]> wrote:
>
>
>
> Folks,
>
>
>
> https://datatracker.ietf.org/doc/draft-ietf-sacm-coswid/
> <https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-sacm-coswid%2F&data=02%7C01%7Cdavid.waltermire%40nist.gov%7C91c6b28941ce4a772c3c08d6ffd8f9e3%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C1%7C636977704712452256&sdata=PAS8N3br%2FthOhPonKJzuWUlIsn9bQvqSZ%2F6hbE3%2FhDU%3D&reserved=0>
>
>
>
> Please reply to this email thread with an indication that you have read
> the document, any comments you may have, and your assessment of whether or
> not it is ready to proceed to publication.
>
>
>
> [email-masked]
> [email-masked]

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 5 Jul 2019 12:21:06 +0200

Nice piece of work.
While I didn’t have time to fully check the whole I-D, I skimmed it, and came up with the following.  I’ll also send a few editorial comments to the authors.

Grüße, Carsten

# Major

The term "private use" is used repeatedly but not explained.
Is this meant for random software authors to dump random information
into their coswid tags?  Are there any usage guidelines?  This sounds
like an X-Dash problem waiting to happen (please see RFC 6648).

The document qualifies some values as 8-bit, 16-bit etc.  That is
unnecessary.  Any value ranges that are important should be given, and
they need to be consistent (version-scheme cannot be both 8-bit and
have a private use range of 32768-65535).  If a value range is
important, it should also be visible in the CDDL.

The way URIs are used is trampling on the URI scheme space (coswid:,
swidpath:).  Maybe not much can be salvaged there, but shouldn't these
be registered?

# Minor

[SEMVER] -- is this really needed as a normative reference?
Please also compare draft-verdt-netmod-yang-semver

Similarly, [SWID-GUIDANCE] is not a great source for a normative
reference.  AFAICS, this is used to define
"primary/patch/corpus/supplemental".  Can this be drawn out of the
original [SWID]?

I don't think you have a fragment identifier scheme, even though the
media type registration is written for one (with a dangling internal
reference).  Since this is a +cbor media type, any fragment identifier
scheme would also have to include any defined for CBOR itself (none so
far), but beyond that RFC 7049 gives you freedom.  Do you want to use
those fragment identifiers?  If no, please update the fragment
identifier scheme text in the media type registration to no longer
point to it.

Is there a point in carrying around GUIDs in text form?  Text (in RFC
4122 form) is 36 bytes, binary is 16.

> On Jun 27, 2019, at 22:36, Karen O'Donoghue <[email-masked]> wrote:
> 
> Folks,
>

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 5 Jul 2019 12:27:25 +0200

> and ensure normalization of text.

RFC 5198 is almost, but not entirely unlike what you want.
I wrote a quick draft:

https://tools.ietf.org/html/draft-bormann-dispatch-modern-network-unicode-00

Grüße, Carsten

---

From: Karen O'Donoghue <[email-masked]>
Date: Sat, 13 Jul 2019 17:24:15 +0000

Folks,

One week left on this last call…

Thanks in advance for your review and comments!
Karen

Folks,

Thanks!
Karen and Chris

---

From: Adam Montville <[email-masked]>
Date: Wed, 17 Jul 2019 08:30:07 -0500

Sorry for my delay. I’m in favor of progressing this draft.

> On Jul 13, 2019, at 12:24 PM, Karen O'Donoghue <[email-masked]> wrote:
> 
> Folks,
> 
>> On Jun 27, 2019, at 4:36 PM, Karen O'Donoghue <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Folks,
>> 
>> https://datatracker.ietf.org/doc/draft-ietf-sacm-coswid/ <https://datatracker.ietf.org/doc/draft-ietf-sacm-coswid/>
>> 
>> [email-masked] <mailto:[email-masked]>

---

From: Ira McDonald <[email-masked]>
Date: Wed, 17 Jul 2019 09:43:18 -0400

Hi,

+1 to CoSWID.  I have been a strong supporter of CoSWID
all along.  This will be an enabler for SACM and many other
efforts.

Having now looked at Carsten's Modern Network Unicode
and read the good discussion w/ John Klensin and others,
I agree that MNU could evolve into an excellent replacement
for RFC 5198.  Not only CoSWID, but most all of the SACM
drafts would benefit by explicitly addressing normalization
and comparison issues w/ Unicode strings.

Cheers,
- Ira

---

From: Monty Wiseman <[email-masked]>
Date: Wed, 17 Jul 2019 15:10:19 -0400

+1

Monty Wiseman

TCG Infrastructure and TNC work group co-chair

On 7/17/19 9:30 AM, Adam Montville wrote:
>> On Jul 13, 2019, at 12:24 PM, Karen O'Donoghue <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> Folks,
>>
>>> Please reply to this email thread with an indication that you have 
>>> read the document, any comments you may have, and your assessment of 
>>> whether or not it is ready to proceed to publication.
>>>

---

From: "Mark D. Baushke" <[email-masked]>
Date: Thu, 18 Jul 2019 08:12:51 -0700

I have read the "Conscise Software Indentification Tags"
(draft-ietf-sacm-coswid-11) document.

I support this work as a key component in software integrity validation.

I believe this document is ready to proceed to publication.

-- 
Mark Baushke
[email-masked]

Karen O'Donoghue <[email-masked]> writes:

> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_sacm&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=6l1UaIK-spZ6HPOy-7bswQ&m=aSqdHIlNr8pQbnePlv7DAEga9G932Pf_wyx-1dFXEvQ&s=ihL9kufRXA2aOqziFlsdLa-3WT-AG-eCzz27v-yBLds&e=

---

From: Jarrett Lu <[email-masked]>
Date: Thu, 18 Jul 2019 15:43:41 -0700

I have reviewed the current (and  previous) version of the draft. Having
followed the evolution of this document, I am in full support of this work
going forward to publication after authors have addressed the reviewers'
comments.

Regards.

- Jarrett

---

From: "Smith, Ned" <[email-masked]>
Date: Fri, 19 Jul 2019 02:15:43 +0000

+1
Ned Smith

On 7/13/19, 1:35 PM, "sacm on behalf of Karen O'Donoghue" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

Folks,

Folks,

Thanks!
Karen and Chris

---

From: "Nelson, Alexander J. (Fed)" <[email-masked]>
Date: Thu, 25 Jul 2019 00:40:29 +0000

Hi Dave,

I have a *non-blocking* question.

I see this new line 252 in the pull request:
https://github.com/sacmwg/draft-ietf-sacm-coswid/pull/13/commits/fe48345500c5109c062fc2920d81563499af8566#diff-6215c4faa2636284809e7c3c7762b136R252

"""
In most cases, mapping attribute names between SWID and CoSWID can be done automatically by converting between CamelCase and KebabCase attribute names. However, some CoSWID CDDL attribute names show greater variation relative to their corresponding SWID XML Schema attributes. This is done when the change improves clarity in the specification. For example the "name" and "version" SWID fields corresponds to the "software-name" and "software-version" CoSWID fields, respectively. As such, it is not always possible to mechanically translate between corresponding attribute names in the two formats. In such cases, a manual mapping will need to be used.
"""

I have a lingering question after reading this.  "Mechanical translation" to me is unambiguous bidirectional translation.  A mapping of changed names still counts to me as unambiguous bidirectional translation if there is no chance of ambiguity from the shorter source name.  Given the context of where an attribute (such as `name`) is permitted to appear, is there actually any ambiguity possible in the translation process between swid and coswid?

Again, this question is not meant to halt advancing the document to publication.  The text is accurate regardless of the polarity of the response.

--Alex

On Jul 3, 2019, at 1:33 PM, Waltermire, David A. (Fed) <[email-masked]<mailto:[email-masked]>> wrote:

Thanks for the feedback Alex. I’ll fix these issue at the end of the WGLC along with any other comments that come up.

Regards,
Dave

From: sacm <[email-masked]<mailto:[email-masked]>> On Behalf Of Nelson, Alexander J. (Fed)
Sent: Wednesday, July 3, 2019 1:07 PM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [sacm] WGLC for draft-ietf-sacm-coswid

Hello all,

I find this draft to be nearly ready for publication..  There are a few minor editorial issues that should be resolved before publication, listed at the end of this message.  I also found I had a few questions and possible discrepancy identifications, listed first.

Questions:

* Before I started reading the document, I thought that CoSWID would be a losslessly-translatable representation of SWID data, between XML and CBOR.  From Section 2's third paragraph, this is stated to not be a goal feature.  (In case it isn't clear, I don't object to this.)  Is it at least possible to translate from one format to the other, not necessarily bilaterally, and perhaps under certain conditions like "if there are no extension elements or attributes, SWID XML can be mechanically translated to CoSWID"?  From my reading, it looks like that example statement I just wrote would hold.

Editorial issues:

--Alex

Folks,

Concise Software Identification Tags
https://datatracker.ietf.org/doc/draft-ietf-sacm-coswid/<https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-sacm-coswid%2F&data=02%7C01%7Calexander.nelson%40nist.gov%7Ccccd2dc6ec0945b3171f08d6ffdc923e%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C1%7C636977720150173920&sdata=YhUBozxvW75VgvPCbhJIKZrIiFWi5amh%2FbK%2BYh0hDSc%3D&reserved=0>

Thanks!
Karen and Chris
_______________________________________________
sacm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sacm<https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsacm&data=02%7C01%7Calexander.nelson%40nist.gov%7Ccccd2dc6ec0945b3171f08d6ffdc923e%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C1%7C636977720150183913&sdata=q6NOkQpscmwZoKX2w3EHUiDP%2FIFuyq60IKXqdxxt0dc%3D&reserved=0>

---

From: "Waltermire, David A. (Fed)" <[email-masked]>
Date: Thu, 25 Jul 2019 14:51:21 +0000

Carsten,

Thanks for the feedback. I have addressed your comments in -12. My responses are below marked [daw:].

Regards,
Dave

________________________________
From: sacm <[email-masked]> on behalf of Carsten Bormann <[email-masked]>
Sent: Friday, July 5, 2019 6:21 AM
To: Karen O'donoghue <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: [sacm] WGLC for draft-ietf-sacm-coswid

Nice piece of work.

Grüße, Carsten

# Major

[daw:  I reworked the IANA section for registered CoSWID values, providing guidelines on private use and for designated experts. Please let me know if the new text is satisfactory.]

[daw: References to 8-bit, 16-bit etc. have been removed.]

[daw: I added registrations for swid and swidpath.]

# Minor

[daw:  The draft draft-verdt-netmod-yang-semver is way to yang module specific for use here. I don't know of another stable reference for SEMVER. I believe the current SEMVER specification reference is stable. It was at least stable enough for ISO/IEC SC7 to reference it in 19770-2:2015.]

[daw:  No. [SWID-GUIDANCE] clarified the operational roles of primary/patch/corpus/supplemental. It is referenced in CoSWID as an informative reference to identify the source of the paraphrased text in section 1.1. Since it is not being used in a normative way, I don't see any action to take here.]

[daw:  We are good with following along with whatever fragment identifier scheme gets defined for "+cbor". I see no reason to make an adjustment as a result.]

[daw:  I added a 16 byte binary string option to avoid this.]

> https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-sacm-coswid%2F&amp;data=02%7C01%7Cdavid.waltermire%40nist.gov%7Cac79620c9e9541230cee08d701328fcc%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C1%7C636979188981227622&amp;sdata=KRiXDwxHWonk0rZ2kR3ogUACAzVEoL0YglHI%2BFBixt0%3D&amp;reserved=0
>

_______________________________________________
sacm mailing list
[email-masked]
https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsacm&amp;data=02%7C01%7Cdavid.waltermire%40nist.gov%7Cac79620c9e9541230cee08d701328fcc%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C1%7C636979188981227622&amp;sdata=WgkCaYdK5AMlq712RhF%2Fm%2FyEl2LON8a7Pdr1fr4xm2s%3D&amp;reserved=0

---

From: "Waltermire, David A. (Fed)" <[email-masked]>
Date: Thu, 25 Jul 2019 14:56:29 +0000

Alex,

Thank you for your feedback. I have addressed your comments in -12. Responses to your comments are below marked [daw:].

Regards,
Dave

________________________________
From: sacm <[email-masked]> on behalf of Nelson, Alexander J. (Fed) <alexander.nelson=[email-masked]>
Sent: Wednesday, July 3, 2019 1:07 PM
To: [email-masked] <[email-masked]>
Subject: Re: [sacm] WGLC for draft-ietf-sacm-coswid

Hello all,

Questions:

[daw: I added some text to section 2 third paragraph to make the relationship between SWID and CoSWID attribute names more clear. Please let me know if you think more clarification is needed.]

[daw: I added a new section 2.1 "Character Encoding" to address UTF-8 encoding and Net-Unicode. Sections 5.2.1 thru 5.2.5 also require that the registered names are valid according to the XML Schema NMToken data type to ensure compatibility with the SWID specification. This imposes additional constraints on the UTF-8 strings that can be registered.]

[daw: I reorganized the text in section 6 to make the distinction between authoritative and signed more clear.]

Editorial issues:

[daw: Fixed.]

[daw: I clarified that the "x" means the tag was removed.]

[daw: I adjusted the wording in a slightly different way. Is the new wording ok?]

[daw: The index value 7 is used for hash. We didn't reorder the index values since they are already being used in some implementations.]

[daw: Fixed.]

[daw: Fixed.]

[daw: Added a forward reference.]

[daw: Added a discussion around allowing multiple lines.]

[daw: Fixed.]

[daw: Yes. Fixed.]

[daw: Fixed.]

[daw: Fixed.]

[daw: Fixed.]

[daw: I added a reference to the COSE appendix instead.]

--Alex

Folks,

Thanks!
Karen and Chris

---

From: "Nelson, Alexander J. (Fed)" <[email-masked]>
Date: Thu, 25 Jul 2019 15:22:21 +0000

Hi Dave,

I have three replies inline, ~1.5 actionable, denoted [ajn:].

--Alex

On Jul 25, 2019, at 10:56 AM, Waltermire, David A. (Fed) <[email-masked]<mailto:[email-masked]>> wrote:

Alex,

Regards,
Dave

________________________________
From: sacm <[email-masked]<mailto:[email-masked]>> on behalf of Nelson, Alexander J. (Fed) <alexander.nelson=[email-masked]<mailto:alexander.nelson=[email-masked]>>
Sent: Wednesday, July 3, 2019 1:07 PM
To: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sacm] WGLC for draft-ietf-sacm-coswid

Hello all,

Questions:

[ajn: I raised some feedback on this in a separate email thread.  Some more clarification could be used, but it's somewhat academic, so I won't request publication be paused to address it.]

Editorial issues:

[daw: Fixed.]

[ajn: The new wording is ok, though another typo snuck in: "are able to be encodes/decoded" should have "encoded".]

[ajn: Ah, thank you.]

[daw: Fixed.]

[daw: Fixed.]

[daw: Fixed.]

[daw: Yes. Fixed.]

[daw: Fixed.]

[daw: Fixed.]

[daw: Fixed.]

--Alex

Folks,

Concise Software Identification Tags
https://datatracker.ietf.org/doc/draft-ietf-sacm-coswid/<https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-sacm-coswid%2F&data=02%7C01%7Calexander.nelson%40nist.gov%7C61b6262cea9141bbf6dc08d711104e03%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636996634038219161&sdata=vUI%2F%2BYcD%2F6K0kEN%2BxuAWjn6GpN9%2Fz2jQxxf0ITDPKDE%3D&reserved=0>

Thanks!
Karen and Chris

---

From: "Waltermire, David A. (Fed)" <[email-masked]>
Date: Thu, 25 Jul 2019 17:58:25 +0000

Alex,

Thanks again for your reviews. I'll address the typo in the next revision.

Regards,
Dave

-------- Original Message --------
From: "Nelson, Alexander J. (Fed)" <[email-masked]>
Date: Thu, July 25, 2019 11:22 AM -0400
To: "Waltermire, David A. (Fed)" <[email-masked]>
CC: [email-masked]
Subject: Re: [sacm] WGLC for draft-ietf-sacm-coswid

Hi Dave,

--Alex

Alex,

Regards,
Dave

Hello all,

Questions:

Editorial issues:

[daw: Fixed.]

[ajn: Ah, thank you.]

[daw: Fixed.]

[daw: Fixed.]

[daw: Fixed.]

[daw: Yes. Fixed.]

[daw: Fixed.]

[daw: Fixed.]

[daw: Fixed.]

--Alex

Folks,

Thanks!
Karen and Chris