Re: [urn] Namespace Identifier: Requested of IANA - cdx

[[e-mail]]

I've got a number of editorial nits, and one technical question:  Should
it revise the syntax of bom-version based on its underlying semantics?

----------

There are some places where the sentence structure is rough, so you
probably want someone to copy-edit the text.

    Patrick Dwyer, on behalf of OWASP CycloneDX

You probably want to say "on behalf of OWASP", as CycloneDX isn't an
organization.  Alternatively, you may want to conceptualize "the
CycloneDX project" apart from OWASP, in which case you'd say "on
behalf of the CycloneDX project".

    CycloneDX is an open source software bill of materials OWASP
    standard.

I'm not sure of the significance of "open source" here.  Is CycloneDX
only applicable to open-source software?  Or is the standard somehow
open-source?

    The “cdx” namespace is used ...

Better, 'URNs in the "cdx" namespace are used ...'.

    CycloneDX also supports “BOM refs”. BOM refs are unique BOM scoped 
    references to a particular element. A URN with an optional BOM ref 
    f-component can be used to reference an element within another BOM.

    Referencing a specific element in a BOM is particularly relevant for use 
    cases like describing known vulnerabilities in a component in the 
    context of a particular assembled piece of software or embedded device.

This text is interesting, but it seems to me that you'd need quite a
bit more description to enable the reader to understand the import of
BOM refs.  So I think you should trim it back to provide just enough
context for why the grammar specifies f-components.  Say:

    CycloneDX also supports “BOM refs”. A BOM ref is a reference to a
    particular element within a BOM.  A "cdx" URN with an f-component is
    a BOM ref, with the fragment identifier specifying the element
    within the BOM identified by the URN.

That makes the purpose clear without even getting into the details of
what an "element of a BOM" is.

    bom-version            = 1*digit

There are a bunch of interesting questions here!  As written,
bom-version is a string of digits, and "00", "000", "1", and "0001"
are all different.  Is bom-version intended to denote an integer?  If
so, what range does the integer have; specifically, does it include
zero?  If it is intended to be an integer, you should adjust the
syntax to permit only the canonical way of writing those integers.

    CycloneDX URNs are assigned in a decentralised way, using the BOM serial 
    number. CycloneDX BOM serial numbers are unique to a specific BOM. And 
    are version 4 UUID URNs as defined in [RFC4122].

In the first sentence, it would be preferable to say
"bom-serial-number-uuid" rather than "BOM serial number", as that is
what the grammar says -- unless CycloneDX uses the term "BOM serial
number" a lot, in which case I'd change "bom-serial-number-uuid" to
"bom-serial-number" in the grammar.

In the second sentence, I'd clarify the correspondence between serial
numbers and BOMs by making both parts of the sentence singular, "A
CycloneDX BOM serial number is unique to a specific BOM."

I would clarify the third sentence by saying "A CycloneDX BOM serial
number is a version 4 UUID as defined in [RFC4122]."  (A BOM serial
number *itself* isn't a URN, as it is a UUID [RFC4122] and does not
start with "urn:".)

    Additionally, there are no specification limitations on what information 
    can be included in a “BOM ref”. When using BOM refs for f-components, 
    consideration must be given to any restrictions imposed on sharing of 
    information within a BOM. And what information may “leak” by including a 
    BOM ref as an f-component in a CycloneDX URN.

    For producers of BOMs who have high confidentiality requirements it is 
    recommended to use UUIDs for BOM refs.

I'm not clear what exactly counts as a "BOM ref" -- Is it the
URN-with-f-component, or is it just the f-component?  Or is it the
abstract concept and we also use the term vaguely to mean both the
URN-with-f-component and f-component?  It might be better to limit
this paragraph to talking about f-components to avoid any
complications:

    Additionally, there are no specification limitations beyond
    [RFC3986] on what can be included the f-component.  Given that
    f-components may be published in CyclineDX URNs, producers of BOMs
    should avoid using any value on which there are sharing
    restrictions.  For producers of BOMs who have high confidentiality
    requirements, it is recommended to use UUIDs for f-components.

--

    Although CycloneDX BOMs already use a UUID URN to identify a BOM this 
    information isn’t sufficient when referencing a BOM.

    A particular BOM may be revised over time. Especially in the case of 
    legacy software as mistakes and omissions are corrected. In this 
    scenario the BOM serial number remains static and the version is 
    incremented.

    It also isn’t sufficient for use cases that require referencing a 
    specific component within a BOM.

I think this can be clarified considerably:

    Although CycloneDX BOMs may use a UUID URN to identify a BOM via
    its BOM serial number, the serial number isn’t sufficient when
    referencing a BOM because a particular BOM may be revised over
    time.  Even in the case of legacy software that is not
    conceptualized as changing, mistakes and omissions can be
    corrected over time causing changes in the BOM.  This is allowed
    for by successive "cdx" URNs in which the BOM serial number
    remains static and the version is incremented.

Dale