Re: draft-cardona-cablelabs-urn-02

[Leslie Daigle <[e-mail]>]

As a point of order -- the proponents of the namespace are supposed to 
forward the I-D to this mailing list for a review when (they believe) it 
is ready for publication.

Alfred is helping you out with some advance input!  but, I don't recall 
having seen it here before, and I will still ask you to formally send 
the I-D to the list when you're ready to consider publishing it.

Thanks,
Leslie.

Alfred � wrote:
> 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.
> 

-- 

-------------------------------------------------------------------
"Reality:
      Yours to discover."
                                 -- ThinkingCat
Leslie Daigle
[e-mail]
-------------------------------------------------------------------