Subject: request for registration of the "scte" URN namespace

From: Darshak Thakore <[email-masked]>
Date: Tue, 5 Apr 2016 18:34:55 +0000

Hi all,

The Society of Cable Telecommunications Enginners (SCTE) would like to register the “scte” URN namespace in the IANA registry located here:

http://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml

Pursuant to the instructions provided in RFC 3406, Section 4.3, I am sending the request to the above address. An I-D using the template in Appendix A of RFC 3406 has been submitted to the IETF. The I-D requesting the URN registration and providing the relevant information is available here:

https://tools.ietf.org/html/draft-dthakore-scte-urn-00

We would like the group to review the draft and provide any necessary comments/feedback.

Regards,
Darshak Thakore
Lead Software Architect
CableLabs

---

From: Ted Hardie <[email-masked]>
Date: Tue, 12 Apr 2016 11:41:38 -0700

Hi Darshak,

Thanks for the submission; the IETF week has just ended, so it's possible
that folks will bring this back to the fore.

I note that the document has a "TBD" for the mailing address of the
designated contact.  That will need an update.  Second, you use the syntax:

urn:scte:{SCTEresource}:{ResourceSpecificString}

to describe the structure.  You don't appear to include ABNF for each of
the substructures, though; did you intend to describe them?

You also cite the "SANN" as the intended numbering authority, but the
citation is simply a repetition of the acronym expansion.  What's the
actual status of this body?

regards,

Ted HArdie

On Tue, Apr 5, 2016 at 11:34 AM, Darshak Thakore <[email-masked]>
wrote:

> Hi all,
>
> The Society of Cable Telecommunications Enginners (SCTE) would like to
> register the “scte” URN namespace in the IANA registry located here:
>
> Pursuant to the instructions provided in RFC 3406, Section 4.3, I am
> sending the request to the above address. An I-D using the template in
> Appendix A of RFC 3406 has been submitted to the IETF. The I-D requesting
> the URN registration and providing the relevant information is available
> here:
>

---

From: Darshak Thakore <[email-masked]>
Date: Tue, 12 Apr 2016 19:48:14 +0000

Hi Ted,

Thanks a lot for the quick turn around on the feedback. Comments inline

On 4/12/16, 12:41 PM, "Ted Hardie" <[email-masked]<mailto:[email-masked]>> wrote:

Hi Darshak,

Thanks for the submission; the IETF week has just ended, so it's possible that folks will bring this back to the fore.

I note that the document has a "TBD" for the mailing address of the designated contact.  That will need an update.  Second, you use the syntax:

to describe the structure.  You don't appear to include ABNF for each of the substructures, though; did you intend to describe them?

DT>> I’ll update the designated contact address shortly. The ABNF for {SCTEresource}:{ResourceSpecificString} will be in the SCTE specs. Do I need to provide it here or is it ok if I simply state that the specific tokens will be defined in relevant SCTE specs ?

You also cite the "SANN" as the intended numbering authority, but the citation is simply a repetition of the acronym expansion.  What's the actual status of this body?

DT>> I’m in the process of procuring the URL to the document and update it shortly.

Regards,
Darshak

regards,

Ted HArdie

On Tue, Apr 5, 2016 at 11:34 AM, Darshak Thakore <[email-masked]<mailto:[email-masked]>> wrote:
Hi all,

Regards,
Darshak Thakore
Lead Software Architect
CableLabs

---

From: Ted Hardie <[email-masked]>
Date: Wed, 13 Apr 2016 12:45:50 -0700

On Tue, Apr 12, 2016 at 12:48 PM, Darshak Thakore <[email-masked]>
wrote:

>
> Hi Ted,
>
> DT>> I’ll update the designated contact address shortly. The ABNF for
> {SCTEresource}:{ResourceSpecificString} will be in the SCTE specs. Do I
> need to provide it here or is it ok if I simply state that the specific
> tokens will be defined in relevant SCTE specs ?
>
>
Well, you're breaking up the namespace specific string into sub-portions,
which is usually a hint that they will be described in what follows.  If
you can cite those in some other documents, that should be okay (though a
little odd).  To confirm my understanding, though, "will be defined" means
that they are not yet?  If that is the case, how certain can you be that
this is the only salient split?

> DT>> I’m in the process of procuring the URL to the document and update it

I see, thanks for the update.

regards,

Ted Hardie

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 13 Apr 2016 15:46:41 -0400

Overall, the document looks fine, but there are a bunch of wording
improvements that should be done.

section 1

   SCTE standards work includes: data and telephony
   over cable; application platform development; digital video;
   emergency alert systems; network monitoring systems; cables,
   connectors and amplifiers; construction and maintenance practices;
   energy management, and more.

The final comma in this sentence should be a semicolon.

section 2

         Name: Society of Cable Telecommunications Engineers
         Address: 140 Philips Road, Exton, PA 19341-1318, USA
      Designated contact

         Role: Manager, Standards
         Email: TBD

It looks like there should be an empty line above "Designated contact".

As Ted noted, an e-mail address is needed.

   Declaration of syntactic structure:

      The Namespace Specific String (NSS) of all URNs that use the
      "scte" NID will have the following structure:

      where the "SCTEresource" is a US-ASCII string that conforms to the
      URN syntax requirements of [RFC2141].
      SCTE will maintain a naming authority, the SCTE Assigned Names and
      Numbers [SANN] specification, that will contain the assignment of
      SCTE resource classes and the specific registration values
      assigned for each resource class.  This specification will be
      published on the SCTE Standards Program website.

Is there supposed to be an empty line above "SCTE will maintain"?  The
flow of the words is interrupted.

The syntax you show is the structure of all "scte" URNs; the NSS has
the structure "{SCTEresource}:{ResourceSpecificString}".

The text should state that the string "{SCTEresource}" specifies the
resource class, and that "{ResourceSpecificString}" specifies the
resource within the class.

The phrase "conforms to the URN syntax requirements of [RFC2141]" is
vague; it would be better to say that it "conforms to <nonterminal> of
[RFC 2141]", where <nonterminal> is the syntax you desire.  A
specification like this needs to be given for both "{SCTEresource}"
and "{ResourceSpecificString}".  Beware that if the definition of
"{SCTEresource}" allows it to contain a colon, then a "scte" URN
cannot be uniquely parsed, and so you probably want to forbid that.

      SCTE will maintain a naming authority, the SCTE Assigned Names and
      Numbers [SANN] specification, that will contain the assignment of
      SCTE resource classes and the specific registration values
      assigned for each resource class.  This specification will be
      published on the SCTE Standards Program website.

Since "SANN" is not a reference but an abbreviation of what preceeds
it, it should probably be put in (...) rather than [...].

The phrase "This specification" could refer either to the draft/RFC
or SANN.  It would be clearer to change it to "SANN".

      SCTE could allow the use of experimental type values for testing
      purposes only.  Note that using experimental types may create
      collisions as multiple users may use the same values for resources
      and specific strings.

The terms "class" and "type" seem to be used interchangeably for the
subsets of resources named by these URNs.  If so, one term should be
used throughout.

I think "SCTE may allow" is better than "SCTE could allow", since the
draft/RFC is to specifically allow SCTE to do so.

      Each such resource may have three types registration activities:

This sentence is ungrammatical.  In addition, it isn't resources that
have three registration activities; there are three types of
registration activities, some of which involve specific resources and
some of which involve sets of resources.

   1.  Registered values associated with SCTE documents or services
   2.  Registration of values or sub-trees to other entities
   3.  Name models for use in experimental purposes

These items are not grammatically parallel; one designates an scte
URN, one designates the act of registering a set of URNs, and one
designates a "name model".

      The namespace is not listed with a resolution discovery system;
      this is not applicable for this URN registration.

It would be simpler to say "the namespace does not have a resolution
discovery system."

section 3

   The following example represents a hypothetical URL that could be
   assigned by SCTE.
   urn:scte:dash:2015

Better to say "following example is a".

Should be an empty line before "urn:scte:dash:2015", or indent that
line.

   This example defines the URN to be used for for ANSI/SCTE 214-1 2015
   "MPEG DASH for IP-Based Cable Services Part 1: MPD Constraints and
   Extensions"

"for for" should be "for", and might be clearer as "for the standard".

Missing full stop at the end of the sentence.

section 4

   SCTE develops specifications that may require the use of data models.
   URN Namespaces are key constructs to manage the definitions of those
   data models reliably with persistence and uniqueness.

   The use of URNs should also help specification authors to maintain
   different versions of URNs and dependencies between URNs across
   different versions of SCTE specifications if they so wish.

I think "URN Namespaces" here should be "URN namespaces".

It's not clear to me how URNs assist in the activities described in
the preceding two paragraphs.  Is it possible to rewrite them to
explain how?  Does the assistance extend beyond simply providing a set
of persistent and unique names for things?

Dale