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

[Ballot comment]
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

[Ballot comment]
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

[Ballot comment]
suzanne wolf

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

[Ballot comment]
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.

[Ballot comment]

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.

[Ballot comment]
John Klensin has raised an issue that this should be held up until the urnbis working group has finished its work on updating the URN namespace registration documents.  I don't agree: I think we need to proceed with namespace requests as we have done, and have any new mechanisms take effect only when the documents defining them are complete and approved.

IESG/Authors/WG Chairs:

IANA has reviewed draft-higgs-hbbtv-urn-00.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

IANA's reviewer has the following comments/questions:

Upon approval, IANA will register the following in the Formal URN Namespace registry at http://www.iana.org/assignments/urn-namespaces:

hbbtv  [this document]

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (A Uniform Resource Name (URN) Namespace for the HbbTV Association) to Informational RFC


The IESG has received a request from an individual submitter to consider
the following document:
- 'A Uniform Resource Name (URN) Namespace for the HbbTV Association'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2015-01-01. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document describes a Uniform Resource Name (URN) namespace for
  the Hybrid Broadcast Broadband TV Association (HbbTV) for naming
  persistent resources defined within HbbTV specifications. Example
  resources include technical documents and specifications, eXtensible
  Markup Language (XML) Schemas, classification schemes, XML Document
  Type Definitions (DTDs), namespaces, style sheets, media assets, and
  other types of resources produced or managed by HbbTV.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-higgs-hbbtv-urn/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-higgs-hbbtv-urn/ballot/


No IPR declarations have been submitted directly on this I-D.

1. Summary

Barry Leiba is the document shepherd and responsible AD.

This document describes and registers a Uniform Resource Name (URN)
namespace for the Hybrid Broadcast Broadband TV Association (HbbTV) for
naming persistent resources defined within HbbTV specifications.
 
2. Review and Consensus

This needs to go through the IETF stream because of the URN namespace
registration rules, but it's mostly pro forma.  The document has been
reviewed on the urn-nid mailing list, and the authors accepted some
comments from there.  Everything should otherwise be ready to go.

3. Intellectual Property

The authors are in full conformance with BCPs 78 and 79.

4. Other Points

None.