Last Call Review of draft-mahesh-etsi-urn-03
review-mahesh-etsi-urn-03-secdir-lc-lonvick-2018-08-02-00

Hi,

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the IESG.
These comments were written primarily for the benefit of the security
area directors. Document editors and WG chairs should treat these
comments just like any other last call comments.

The summary of the review is Ready with Issues.

I am not that familiar with creating and maintaining URNs so please set
me straight and move on if I'm off base here.

Section 2, "URN Specification for ETSI" contains the following:

"ETSI will manage resource classes using the "etsi" NID and will be the
authority for managing resources and associated subsequent strings. ETSI
will guarantee the uniqueness of the strings themselves, or it may
permit secondary responsibility for certain defined resources."

But then says:

"ETSI may allow for use of experimental type values for testing purposes
only. Note that using experimental types may create collision as
multiple users may use the same values for different resources and
specific strings."

It looks like RFC 8141 gives guidance that experimental use of URN
namespaces is to be done using RFC 6963 (URNs for "Examples".) RFC 8184
does not address establishing or using namespaces under the subsequent
strings for experimental use, but I could see that the registered owner
of the namespace could make a designation for that purpose. That being
said, I think that the two statements above are in conflict in the
document and should be clarified.

Perhaps it would be better to reconstruct the second paragraph to say
something like:

"ETSI may allow for use of experimental type values for testing purposes
only. Some experimentation may be controlled by ETSI within a subsequent
string to ensure that there will be no namespace collisions among
participants. Other experimentation may be controlled within a secondary
namespace that may allow collisions, but this experimental use will be
constrained. All other experimentation must follow the guidance set
forth in RFC 6963."

Just as a nit, the Security Considerations section should be revised as
it seems to be a bit unclear.
Current:

    There are no additional security considerations other than those
    described above, and are normally associated with the use and
    resolution of URNs in general, which are described in Function
    Requirements for URN [RFC1737 <https://tools.ietf.org/html/rfc1737>],
    Uniform Resource Names (URNs) [RFC8141
    <https://tools.ietf.org/html/rfc8141>].

Suggested:
    There are no additional security considerations other than those
    described above, and_those_  normally associated with the use and
    resolution of URNs in general._These a__re generally_  described in
    Function_al_ Requirements for_Uniform Resource Names_  [RFC1737
    <https://tools.ietf.org/html/rfc1737>],_and_  Uniform Resource Names (URNs)
    [RFC8141 <https://tools.ietf.org/html/rfc8141>].

Best regards, Chris