A Uniform Resource Name (URN) Namespace for the Hybrid Broadcast Broadband TV (HbbTV) Association
draft-higgs-hbbtv-urn-01

I went to look at the URN-NID discussion of this draft and found a short thread [1]. It doesn’t seem like Ted’s question about structure was ever really addressed. I looked back at a couple of other recent NID registrations [2] [3] and they both provide more information about the URN structure than the HbbTV document does. But perhaps the authors of the HbbTV doc were using a different document as an example, e.g., RFC 5328 [4]. It’s unclear to me whether in general we should be preferring the approach taken in [2] and [3] or the approach taken in [4], and since the HbbTV authors didn’t answer that part of Ted’s question I don’t know if they favor the [4] approach or just missed it.

I bring this up on this thread because if we’re going to say the URN-NID list provides sufficient review, at least the reviews that appear there should have full responses. Not clear to me whether that occurred in this case or not.

[1] http://www.ietf.org/mail-archive/web/urn-nid/current/msg01276.html
[2] http://tools.ietf.org/html/draft-murdock-nato-nid-03
[3] http://tools.ietf.org/html/draft-ietf-salud-alert-info-urns-14
[4] http://tools.ietf.org/html/rfc5328

from suzanne wolf opsdir review

Hello,

I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the operational area directors.

Document editors and WG chairs should treat these comments just like any other last call comments.

Assessment: this looks ready to go, with one suggestion, below.

The text, and the datatracker history, suggest this is a straightforward registration of what's largely a proprietary namespace, in support of interoperability among HBBTV participants and the larger internet. From a quick reading of RFC 3406, I think this looks completely consistent with the purpose of the registry.

From an ops perspective, imagining I might see an hbbtv URN in the wild, I think the draft answers the key questions I'd have, namely whether this URN space is published and reserved, format rules, and where to go for more information about how to validate or use such URNs.

The only gap I can see against the RFC 3406 criteria is in the "Community Considerations" section, which RFC 3406 suggests should describe whether the registry is open or closed. The document is clear that the HBBTV Association is the registration authority, but doesn't say whether only HBBTV members can participate in developing/publishing specifications that define entries in this registry, or there's a process for non-members to do so, i.e. that these URNs could be legitimately in use outside of the HBBTV Association's specifications. It's implied elsewhere that these URNs will be included only in specifications developed within the HBBTV association, but as a possibly-curious operator of internet services, I'd appreciate a sentence or two more about how open the process might be. 

The requested registry entry just seems to be the open documentation that this namespace exists and where to go to find out more about how particular URNs in it might be used. This promotes interoperability and should make operators' lives slightly easier for being available. 


thanks,
Suzanne

I agree with Stephen's comment and would also like to see some text added around those points in the Security Considerations section.

I may have misunderstood John Klensin's point, but I thought he was saying that at some point we ought to be asking for reviews on the URNbis mailing list because we might get something useful back, and that he didn't think it was important to start that habit with this document. 

I agree that there's no reason to hold this document up while we decide whether or not we want to start asking for reviews of documents like this one.

I do not agree that there are no new security
considerations here. This is a case where we are
enabling better Internet access from, and importantly
also to, devices that have traditionally not been on
the net. There are many cases where the implementation
of such devices are not sufficiently robust to
withstand the threats that are seen on the Internet.
And there have been cases already where browsers built
in to TV sets have been found to not even honor the
SOP. I would therefore encourage the authors to include
a note about that, ideally with some reference to
material that would help relevant device developers to
do a good job on security. (This is not a DISCUSS as I
think the probability of such new text being useful is
probably too small to insist, but who knows it might
help so would be good to include.)

I fully agree that holding this up for some urnbis
work would not be justified.