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

["Waltermire, David A. (Fed)" <[e-mail]>]

Carsten,


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

Regards,
Dave

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

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

[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.]

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.

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

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?

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

# Minor

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

[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.]

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

[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.]

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.

[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.]

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

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


> On Jun 27, 2019, at 22:36, Karen O'Donoghue <[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://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
>
> 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]
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