Hi,

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 with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review.  Document editors and WG chairs should treat these comments just like any other last call comments. 

(The assignments sheet listed draft-faltstrom-uri-10, but I waited for draft-11, which came out late last week in response to some earlier LC comments. The author and shepherd don't anticipate any problem with keeping it on the March 5 telechat agenda. The changes were significant-- the underlying registry for service type lookups was changed, resulting in text changes particularly in configuration examples-- but appear to be correct.)

Summary: Technical content is ready to go, with one note (below).

This document should ship. It's documenting the use of a DNS RRtype that was already delegated by Expert Review some time ago. In general, moving the RRtype registry to Expert Review from IETF Consensus was A Good Thing(™), but it does mean we don't always have RFCs fully documenting the use of an RRtype, which can limit adoption and interoperability of an otherwise useful new RRtype. People ought to be encouraged to write RFCs that provide guidance on how to use an RRtype, EDNS option, etc. that a developer might otherwise overlook.

Note: There was a question in an earlier LC comment about the example in Section 6. Currently Section 6 is titled "Examples," but there's only one, Section 6.1. Just for style/readability this should be made consistent-- if there's no other example for Section 6, it should be retitled and the subsection header removed.

The current draft has an intended status of PS. It seems to me that Informational would work just as well, since the RFC isn't necessary to get the codepoint delegation. But we've had this issue come up in DNSOP on a couple of occasions, for an RFC describing the use of a codepoint that's already been delegated, and we don't really  have a consistent view to offer.


Suzanne