Re: [sacm] IETF LC Directorate reviews for draft-ietf-sacm-coswid

[Henk Birkholz <[e-mail]>]

Hi Roman,
hi list,

the editors finally managed to find joint work time to address the 
remaining issues! To retain some readability, the corresponding 
responses are included in the previous message as a reply to your 
initial email (which actually should have been a following message, but 
I messed that sequence up :-)

Viele Grüße,

Henk

On 13.01.22 22:56, Roman Danyliw wrote:
> Hi!
> 
> Checking in again.  What is the notional schedule to resolve this feedback?
> 
> Regards,
> Roman
> 
>> -----Original Message-----
>> From: Roman Danyliw <[e-mail]>
>> Sent: Friday, December 3, 2021 1:40 PM
>> To: Roman Danyliw <[e-mail]>; <[e-mail]> <[e-mail]>
>> Subject: RE: IETF LC Directorate reviews for draft-ietf-sacm-coswid
>>
>> Hi!
>>
>> I wanted to check in on the progress of addressing this IETF LC feedback.  At
>> IETF 112, we had discussed and agreed that these would be responded to by
>> the week after the meeting (Friday, Nov 19).
>>
>> Thanks,
>> Roman
>>
>>> -----Original Message-----
>>> From: sacm <[e-mail]> On Behalf Of Roman Danyliw
>>> Sent: Thursday, October 21, 2021 10:16 AM
>>> To: <[e-mail]> <[e-mail]>
>>> Subject: [sacm] IETF LC Directorate reviews for draft-ietf-sacm-coswid
>>>
>>> Hi!
>>>
>>> Thanks for -19 of draft-ietf-sacm-coswid.  Since the conclusion of
>>> IETF LC, I reviewed it based on the provided feedback.  I didn't see
>>> direct replies to the directorate reviews but from cross-walking their
>>> feedback against the -18-to-19 diff, I believe the following are still
>> unresolved/undiscussed.
>>>
>>> (1) Scott Bradner did an OPSDIR review --
>>> https://datatracker.ietf.org/doc/review-ietf-sacm-coswid-18-opsdir-lc-
>>> bradner- 2021-08-07/.  The following feedback does not appear to be
>>> discussed or
>>> resolved:
>>>
>>>> along the same line - it would seem to me that the IANA repository
>>>> should be at https://www.iana.org/assignments/coswid  (or co_swid)
>>>> not https://www.iana.org/assignments/swid
>>>
>>> I believe the comment is about the following text in a few places in
>>> Section
>>> 6.2.*:
>>>
>>>     [TO BE REMOVED: This registration should take place at the following
>>>     location: https://www.iana.org/assignments/swid]
>>>
>>> Earlier in the text in Section 6.2:
>>>
>>> "6.2.  Software Tag Values Registries
>>>
>>>     The following IANA registries provide a mechanism for new values to
>>>     be added over time to common enumerations used by SWID and CoSWID."
>>>
>>> It would seem that if in fact things should stay in
>>> "assignments/swid", there is a missing registration procedure item --
>>> nothing can be added if it isn't in the SWID specification.  I under
>>> the impression from earlier conversations that we wanted to provide
>>> flexibility for CoSWID to potentially extend it's own data model
>>> independent of SWID (i.e., there could be data elements in CoSWID that
>>> were not in SWID).  If so, this suggests that "assignment/coswid" should be
>> used instead (as Scott was suggesting).
>>>
>>> (2) Rich Salz did an ARTART review --
>>> https://datatracker.ietf.org/doc/review-
>>> ietf-sacm-coswid-18-artart-lc-salz-2021-08-02/.  The following
>>> feedback does not appear to be discussed or resolved:
>>>
>>>> In 2.3, why are there three separate bools for
>>>> corpus/patch/supplemental as
>>> opposed to a single enumeration?
>>>
>>> If this is a design choice, please answer Rich.
>>>
>>>> Can the tag-id be a digest of the source file?
>>>
>>> I think the answer is yes.  It might be worth saying so.
>>>
>>>> What are the implications of it not being unique? That should be
>>>> listed in the
>>> security considerations.
>>>
>>> I see that this new text was added: "Failure to ensure global
>>> uniqueness can create ambiguity in tag use since the tag-id serves as
>>> the global key for matching and lookups".  To Rich's point, there are
>>> likely security implications to this collision.  Please explicitly describe those.
>>>
>>> (3) Robert Sparks did a SECDIR review --
>>> https://datatracker.ietf.org/doc/review-ietf-sacm-coswid-18-secdir-lc-
>>> sparks- 2021-08-11/.  The following feedback does not appear to have
>>> been discussed or resolved:
>>>
>>>> Consider RFC6648 (BCP 178) where you are reserving "x_" name
>>>> prefixes for
>>> private use.
>>>
>>> Section 4.2 says:
>>>
>>>     The values above are registered in the IANA "Software Tag Entity Role
>>>     Values" registry defined in Section 6.2.5.  Additional values will
>>>     likely be registered over time.  Additionally, the index values 128
>>>     through 255 and the name prefix "x_" have been reserved for private
>>>     use.
>>>
>>> Section 6.2.5 says:
>>>
>>>                     +=========+=========================+
>>>                     | Range   | Registration Procedures |
>>>                     +=========+=========================+
>>>                     | 0-127   | Standards Action        |
>>>                     +---------+-------------------------+
>>>                     | 128-255 | Specification Required  |
>>>                     +---------+-------------------------+
>>>
>>>                 +=======+=================+=================+
>>>                 | Index | Role Name       | Specification   |
>>>                 +=======+=================+=================+
>>>                 | 0     | Reserved        |                 |
>>>                 +-------+-----------------+-----------------+
>>> ...
>>>                 +-------+-----------------+-----------------+
>>>                 | 7-255 | Unassigned      |                 |
>>>                 +-------+-----------------+-----------------+
>>>
>>> >From the Sec 6.2.5 text, it looks like values 128 - 255 could in fact be
>> assigned.
>>> However, Sec 4.2 says they are reserved for private use.  There may
>>> other cases of this.
>>>
>>> Thanks,
>>> Roman
>>>
>>> _______________________________________________
>>> sacm mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/sacm
> 
> _______________________________________________
> sacm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sacm