draft-cardona-cablelabs-urn-02

[Alfred Hönes <ah at TR-Sys.de>]

Hello,
I apologize for the belated review, but things happen ...

I have a few remarks on your I-D, draft-cardona-cablelabs-urn-02,
mostly editorial in nature.


(1)  Abstract (ff.)

In some places in the draft text, I find terminological confusion
between "URN" (Uniform Resource Name") and "URN Namespace".
The first instance already is in the abstract; others will be
corrected as well below without further mention of the issue.

I suggest to correct the terminology, add precision and clarify
the first sentence in the Abstract as follows:

|  This document describes the Namespace Identifier (NID) for Uniform
|  Resource Namespace (URN) resources published by Cable Television
   Laboratories, Inc. (CableLabs).  CableLabs defines and manages
   resources that utilize this URN identification model.  Management
   activities for these and other resource types are handled by the
   manager of the CableLabs' Assigned Names and Numbers registry.
---
|  This document describes the Namespace Identifier (NID) 'cablelabs'
|  for Uniform Resource Names (URNs) used to identify resources
   published by Cable Television Laboratories, Inc. (CableLabs).
   CableLabs defines and manages resources that utilize this URN
   identification model.  Management activities for these and other
   resource types are handled by the manager of the CableLabs' Assigned
   Names and Numbers registry.


(2)  Section 1, 2nd para -- multiple textual improvements

   Occasionally, CableLabs specifications efforts require URN namespaces
   that are managed so that they are unique and persistent.  To ensure
   that the uniqueness is absolute, the registration of specific NID for
   use by CableLabs is being specified in this document, in full
   conformance with the NID registration process specified in [RFC3406].
---
|  Occasionally, CableLabs specification efforts require identifiers in
|  a managed namespace so that they are unique and persistent.  To
|  ensure that the uniqueness is absolute, the registration of a
|  specific Uniform Resource Name (URN) [RFC2141] Namespace ID (NID) for
   use by CableLabs is being specified in this document, in full
   conformance with the NID registration process specified in [RFC3406].


(3)  Section 2

(3a)  Registration Information:  clause

The draft requests:

|       registration date: YYYY-MM-DD [RFC Editor: Please replace YYYY-
|       MM-DD with the publication date of this RFC.]

Procedurally, that is impractical (see the RFC Editor process
flowchart), because IANA action needs to be complete (but not yet
published) before the draft enters the AUTH48 state for final author
(and AD) review and signoff.  Usually, the date of approval of the
document is conceived as the act establishing the authority for the
registration and hence is used in the IANA registry and in the
published document.  Therefore, I suggest a more practical text:

|       registration date: YYYY-MM-DD
|            [RFC Editor: Please replace YYYY-MM-DD with the date
|            of approval of this document for publication as an RFC.]

(3b)  Declaration of syntactic structure:  clause

There is a contradiction in the draft text:

|       The Namespace Specific String (NSS) of all URNs that use the
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        "cablelabs" NID will have the following structure:
|       urn:cablelabs:{CLresource}:{CLResourceSpecificString} where the
        ^^^^^^^^^^^^^^
        "CLresource" is a US-ASCII string that conforms to the URN
        syntax requirements specified in [RFC2141] and defines a
|       specific class of resource type.  Each resource type will have a
        specific labeling scheme that is covered by
        "CLResourceSpecificString", which also conforms to the naming
        requirements of [RFC2141].

The pattern indicated is *not* for the NSS (only) as explained in the
prose, but for a full 'cablelabs' URN.  That's confusing.

Therefore, I strongly recommend to drop the constant elements not
being part of the NSS from the pattern (and reformat the text for
enhanced readability).  The text also is poorly balanced, placing
the restrictions for one syntactical element in the "where" clause
of the first sentence and comparable information for the other
element into a second sentence.  I recommend to use shorter,
independent sentences.  Also, the term 'class', once introduced
should preferably also be used to denote that subject.

Arguably, "CLresource" is a misnomer, "CLclass" would be better,
and for uniformity, "CLResourceSpecificString" should then be
replaced by "ClclassSpecificString".

In total, still disregarding this final observation, the paragraph
above should better say:

        The Namespace Specific String (NSS) of all URNs that use the
        "cablelabs" NID will have the following structure:
|               {CLresource}:{CLResourceSpecificString}
|
|       The "CLresource" is a US-ASCII string that conforms to the URN
        syntax requirements specified in [RFC2141] and defines a
|       specific class of resource type.  Each class will have a
        specific labeling scheme that is covered by
        "CLResourceSpecificString", which also conforms to the naming
        requirements of [RFC2141].

(4)  Ceterum censeo ...

Apparently, this draft shares a lot of common text with other
documents.
If this draft is not the original source of that text, it is
deemed a question of politeness to recognize the authorship
in an 'Acknowledgments' section at the end of the document --
and arguably the applicable copyright rules (see BCP 78 and
the IETF Trust web site) even make this a requirement.


Kind regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  ah at TR-Sys.de                     |
+------------------------+--------------------------------------------+