Last Call Review of draft-faltstrom-uri-10
review-faltstrom-uri-10-opsdir-lc-woolf-2015-03-01-00

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