Re: [sacm] Revised ID Needed: draft-ietf-sacm-coswid-21

[Henk Birkholz <[e-mail]>]

Hi Roman,

a big thank you for your support of steering the various inputs. That 
really helped us moving forward.

As a result, there is now:

> https://github.com/sacmwg/draft-ietf-sacm-coswid/pull/50

Individual commits addressing distinguishable topics, as well as 
additional comments are in-line. I messed up one commit (as it addresses 
two issues) and one issue we will address in a separate email (as is it 
not solved by a simple commit).

Viele Grüße,

Henk

On 06.05.22 15:26, Roman Danyliw wrote:
> Hi!
> 
> Thanks for publishing -21 in response to IESG review.  I was asked to clarify why draft-ietf-sacm-coswid-21 is in "Revised ID Needed" state -- a number of COMMENTs from the IESG review still need attention.  Specifically:
> 
> [Source: https://datatracker.ietf.org/doc/draft-ietf-sacm-coswid/ballot/]
> 
> ==[ snip: Francesca's position ]==
> Francesca Palombini No Objection
> 
> 1. -----
> 
>     *  If the patch item is set to "true", the tag SHOULD contain at
>        least one link item (see Section 2.7) with both the rel item value
>        of "patches" and an href item specifying an association with the
>        software that was patched.
> 
>     *  If the supplemental item is set to "true", the tag SHOULD contain
>        at least one link item with both the rel item value of
>        "supplemental" and an href item specifying an association with the
>        software that is supplemented.
> 
> FP: This is missing text about why these are SHOULD and not MUST or MAY. I agree with John Klensin, who formulated it very clearly:
> 
> If SHOULD is used, then it must be accompanied by at least one of:
>   (1) A general description of the character of the exceptions and/or in what areas exceptions are likely to arise.  Examples are fine but, except in plausible and rare cases, not enumerated lists.
>   (2) A statement about what should be done, or what the considerations are, if the "SHOULD" requirement is not met.
>   (3) A statement about why it is not a MUST.
> 
> [Roman on -21] Thanks for the new language.  It doesn't appear to provide much clarification.  The preamble to the bulleted list says "If any of these constraints is not met, a signed tag cannot be used anymore as a signed statement."
> 
> ** I don't follow what "cannot be used anymore" means.  Is that saying that a tag is signed with a valid signature, but the contents don't make sense so it should just be ignored?
> 
> ** I'm not sure how to assess conformance when the four subsequent bullets include a MUST (bullet 1), SHOULD (bullet 2), SHOULD (bullet 3) and MUST (bullet 4).  If one treats conformance with the mindset of boolean algebra - the bullet 2 and 3 are irrelevant because the weaker SHOULD could go either way.
To stay consistent and aligned with the SWID specification all 
(remaining) bullet items are now MUST statements. The statement on 
supplemental tag was removed as the index 11 definition in Section 4.4. 
sufficiently defines the use of supplemental tag use and conditions when 
to use it and does not require additional normative statements here.

Fixed in commit a3ea17a

> 
> 
> 2. -----
> 
>     *r  artifact (index: 37): To be used with rel="installation-media",
> 
> FP: Should "installation-media" be "installationmedia" instead?
> 
> [Roman on -21] Please fix

Fixed in commit 0cb7d7d

> 
> 3. -----
> 
>     *  date (index 35): The date and time the information was collected
>        pertaining to the evidence item.
> 
> FP: Please add a reference to Section 3.4.1	[RFC8949] and mention that this is the standard date/time string.
> 
> [Roman on -21] This seems like a helpful clarifying refence for the reader.

Fixed in commit aa1c50d (this also includes the next issue 4, sry)

> 
> 4. -----
> 
>        space, the "decimal" version scheme SHOULD be used.
> 
> FP: Here (and following bullets) is another case that either requires a better context description about the use of SHOULD, or should be rephrased (possibly avoiding the BCP 14 SHOULD) for example:
> 
>        space, it is expected that the "decimal" version be used.
> 
> [Roman on -21] Thanks for the next text of "the "decimal" version scheme SHOULD be assumed." I don't see how it doesn't simply state ("be used" ==> "be assumed") responds to the ambiguity issued suggested by this COMMENT.  Are the "SHOULDs" in these three bulleted clauses needed?

Fixed in commit aa1c50d

> 
> ==[ end ]==
> 
> ==[ snip: Rob's position ]==
> 
> Robert Wilton (was Discuss) No Objection
> 
> Comment (2022-03-21)
> Hi,
> 
> I've discussed this with Roman and Henk and I've agreed to remove my discuss so that the document can be approved and move forward before the new IESG handover.
> 
> The proposal for the two issues below are:
> 
> (1) I think that it would be helpful to have a liaison statement between the SACM WG and ISO that confirms the ongoing expectation and evolution of SWID and CoSWID, i.e., my understanding is that ISO intends to reuse the IANA registry and I think that it would be good to get that more formally confirmed now whilst everyone agrees, so that this doesn't end up being a problem in future when participants have changed and moved on to new projects.  This doesn't need to block the progression of this document, it could be done in parallel.  I also don't think that this had to be written into the document, but possibly a comment in the document may be helpful to set the context for future readers.
> 
> [Roman on -21] Rob cleared his DISCUSS on faith to ensure this document didn't lose positions in the AD turnover at IETF 113.  I have seen no explanation to back to Rob.
> 
> I share Rob's concerns.  The coevolution of this specification with SWID has been a moving target.  When I first inquired about this during AD review in October 2020 (https://mailarchive.ietf.org/arch/msg/sacm/lZsk8wlOprU-WKPxgQAYLfBzDdE/), I heard that CoSWID would independently evolve via it's self-defined IANA registries.  That was consistent with the current text which effectively positioned this document as a fork.  During IETF LC OPSDIR directorate review (https://datatracker.ietf.org/doc/review-ietf-sacm-coswid-18-opsdir-lc-bradner-2021-08-07/) the story changed to SWID now planning to use the IETF registries which suggests that they would co-evolve.  This intended co-evolution was the motivation for keeping certain IANA registry names "swid" as opposed to "coswid".  However, the document still has the following text in Section 1 (which seems to contradict the co-evolution idea):
> 
>     While an attempt to align SWID
>     and CoSWID tags has been made here, future revisions of ISO/IEC
>     19770-2:2015 or this specification might cause this implicit
>     information model to diverge, since these specifications are
>     maintained by different standards groups.
> 
> Can the current swid-coswid coevolution plan be explained?  Can the basis of this plan also be clarified - one approach could be a liaison statement.
> ]
> 
> In addition to this discussion, I believe this document needs to clearly set expectation for implementers with the information we have now - is this CoSWID document (a) an alternative data model for 19970-2:2015/SWID in CBOR with full feature parity (i.e., if I can do it in 19970-2:2015, I can do it CoSWID; and vice versa); or (b) a forked data model of 19970-2:2015/SWID in CBOR that has additional capability (i.e., don't assume that just because something can be represented in the CoSWID data model, that it can be converted/represented in 19970-2:2015 SWID).  Please refine this limited set of expectations as appropriate.

With respect to (1), we'll split this topic off into a separate thread 
and will cover that topic last - if that is okay.

> 
> (2) Regarding the Semver 2.0.0 reference, the suggestion from Roman, which I agree with is that it would be better if the SEMVER reference cited the ITU SWID spec as the normative reference and the current accurate github reference becomes informative.
> 
> [Roman on -21] [SEMVER] is still a normative reference.

Lazy oversight that is fixed in commit e52b0f7

> 
> 
> ==[ snip: from Ben ]==
> 
>>From -20 to -21 a number of internal references changed from Section 2.5
> to "Section 2.4, paragraph 2", which mostly don't seem to make sense to
> me.  Please double-check.
> 
> Section 2.3
> 
>     *  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
> 
> needs a close paren somewhere
> 
> [Roman on -21] Please fix

Fixed in commit 3cb5ea9 and 4f056c5

> 
> Section 9
> 
>     Converse, generators of CoSWID tags need to ensure that only public
> 
> "Conversely"
> 
> [Roman on -21] Please fix.

Fixed in commit fbc5aa9

> 
> ==[ end ]==
> 
> Regards,
> Roman
> 

and thanks again!


> _______________________________________________
> sacm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sacm