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

[Roman Danyliw <[e-mail]>]

Hi!

I was asked to provide a suggestion on how to resolve at least part of Rob's ballot.  My proposal for part of this resolution would be remove a binding between this document and future versions of the SWID, and be clear on the compatibility.  Per Section 1.

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

NEW

Every attempt was made to align the formats SWID and CoSWID tags.  The design of CoSWID allows for a CBOR equivalent representation of any information that can be found in a valid SWID tag per [SWID].  However, CoSWID defines an extension mechanism to its information model via the IANA registries defined in Section 6.  This mechanism allows for additional data elements not defined in this document to be added to CoSWID.  These additional data elements would have no equivalent representation in [SWID].  The IANA registries were designed to allow for the possibility of reuse by other data formats.  

Regards,
Roman

> -----Original Message-----
> From: sacm <[e-mail]> On Behalf Of Roman Danyliw
> Sent: Friday, May 6, 2022 9:26 AM
> To: [e-mail]
> Subject: [sacm] Revised ID Needed: draft-ietf-sacm-coswid-21
> 
> 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.
> 
> 
> 2. -----
> 
>    *r  artifact (index: 37): To be used with rel="installation-media",
> 
> FP: Should "installation-media" be "installationmedia" instead?
> 
> [Roman on -21] Please fix
> 
> 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.
> 
> 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?
> 
> ==[ 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.
> 
> (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.
> 
> 
> ==[ 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
> 
> Section 9
> 
>    Converse, generators of CoSWID tags need to ensure that only public
> 
> "Conversely"
> 
> [Roman on -21] Please fix.
> 
> ==[ end ]==
> 
> Regards,
> Roman
> 
> _______________________________________________
> sacm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sacm