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

["Nelson, Alexander J. (Fed)" <[e-mail]>]

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) <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> On Behalf Of Nelson, Alexander J. (Fed)
Sent: Wednesday, July 3, 2019 1:07 PM
To: [e-mail]<mailto:[e-mail]>
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.

* 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 <[e-mail]<mailto:[e-mail]>> 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%7Ccccd2dc6ec0945b3171f08d6ffdc923e%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C1%7C636977720150173920&sdata=YhUBozxvW75VgvPCbhJIKZrIiFWi5amh%2FbK%2BYh0hDSc%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
[e-mail]<mailto:[e-mail]>
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>