Hi.
A few comments about, or inspired by, this draft. Note that
these comments raise issues that go well beyond the particular
URI draft/proposal. I consider it more important that the
community address those issues than that any particular decision
be made about them for this draft. These comments are
insensitive to the differences between -10 and -11 although I
believe -11 is an improvement. My approval recommendation
appears in a separate, shorter, note posted two days ago
although some of the comments below (particularly item (3),
which recommends removing a section) qualify that recommendation
a bit. That note should probably be read before this one.
While I believe this specification represents a step forward
given the path we are on, it seems to me to raise several
troubling issues. This note is an attempt to address four of
those issues, in no particular order:
(1) Integrity of the standards process.
(2) Iterative DNS use
(3) The state of DDDS and further complicating NAPTR
(4) URIs, URLs, URNs, and the future
So...
(1) Integrity of the standards process.
For many years, it was a key IETF principle that standardization
of a particular technology meant that the community had been
able to review all of the details, make changes where needed,
and then reach rough consensus on the result. The notion of
registering an RRTYPE via Expert Review and then turning around
and asking that it be standardized while claiming that details
(or even design principles) cannot be changed because it is
already registered and in use represents a fundamental departure
from and threat to our historical standardization model. No
malice is implied here, just a bad sequence of steps. I don't
know that it makes a lot of difference how this particular spec
is classified, but, noting that the same situation could apply
to a number of other specifications where registration is by
expert review (Media Types come to mind as do URIs and, if
2141bis is approved in more or less its current form, URNs), it
seems to me that the IETF needs to address this issue, perhaps
confining specifications for already registered names to
Informational or Experimental categories and figuring out an
alternative to expert review for specs that people will want on
the standards track.
(IESG: Please note the interaction between this issue and
draft-leiba-cotton-iana-5226bis.)
Several of the comments below might have been more relevant at
registration time, but, since the spec is going through Last
Call for Proposed Standard, it is at least reasonable to expect
that the spec address and explain the issues involved.
(2) Iterative DNS use
While I wouldn't argue that everything was gotten right, the
original DNS design was structured to minimize the possibility
of multiplicative latency associated with making an arbitrary
number of lookup trips after a particular domain name was
encountered. MX records are restricted to use only primary
names (no aliases) in RDATA precisely to avoid having to do a
third or fourth lookup. If we have decided that multi-stage
iterative lookups are ok after all, that should be documented
and referenced. If (as I believe to be the case) the main
argument for this URI RR is that it is less problematic than
NAPTR, S-NAPTR, U-NAPTR, and (maybe) SRV, then this document
should probably include a plan about phasing some of those, or
at least some instances of some of those, out. If, instead,
these five (or fewer, see below) types of potentially-iterative
indirect references are to exist in parallel, it becomes
reasonable to ask that a standards-track document explain how
many more of them are expected or why we should assume this one
is the last.
Speaking of U-NAPTR, this is either a replacement or it isn't.
"Can be viewed" in Section 8 is unsatisfactory in a
standards-track document. If it is a replacement, then this
document should update RFC 4848 to deprecate that record type
and mechanism. If it isn't, then this document should explain
when to use which one.
To generalize a bit, if we expect this RRTYPE to be broadly
accepted and used, experience suggests that we should make it as
simple and efficient as possible. When we do things that add
complexity (see also (3) below), those require explanation and
justification. Conversely, if we don't have that expectation,
the document should be published as Informational, not proposed
for standardization.
(3) The state of DDDS and further complicating NAPTR
I may have missed important and widely-deployed applications,
but my impression is that DDDS, and the original NAPTR record
format, have not been one of IETF's great success stories, at
least outside of the ENUM space for which NAPTR was first
designed. While I usually believe in general solutions, more
complexity is both an opportunity for sloppy implementations and
potential attack vectors waiting to be discovered and exploited.
The very fact that NAPTR has been evolved into a series of
variations (of which this one may nearly be the latest),
reinforces the hypothesis that it is time to consider a "don't
use this except for existing, established, applications"
applicability statement for NAPTR and, perhaps, a more general
review of DDDS and _its_ applicability.
Especially against that backdrop, it is troubling that, while
the title, abstract, and introduction to this document are about
adding a URI-specific DNS RRTYPE, Section 5 provides an update
to the NAPTR spec itself that modifies and extended that spec.
It does not explain why that modification is desirable and why
this new RRTYPE does not simply replace NAPTR for relevant uses,
nor does it make recommendations as to when one or the other
should be used.
Without the excursion into NAPTR modifications, it appears to me
that this specification does not need DDDS at all (further
reducing complexity).
At least absent clear explanation and justification (and with
modifications to the Abstract, Introduction, and maybe title), I
believe Section 5 should be dropped from this specification.
That would turn it into the pure description of a new RRTYPE
that it claims to be. If modifications to NAPTR and/or
reassessments of DDDS are required, let's put them into an
appropriate separate document and be sure they are properly
reviewed.
If Section 5 were removed, it appears that this specification
would no longer modify/ update RFCs 3404 and 3958, improving its
quality as a self-contained definition of a new RRTYPE.
I have seen no evidence of community review of Section 5.
Because it is rather different from the rest of this
specification, a claim of rough consensus about the document
that includes it and does not show evidence of such review would
be, at best, suspect.
(4) Location abstractions, URIs, URLs, URNs, and the future
Architecturally, having primary user-exposed protocol elements
that identify objects by their rather specific location on the
network is, and has always been, a mistake (in fairness to what
I understand to be the original design of the web and its the
designers, URLs were never expected to be user-visible). The
issues with an approach in which an object is identified by its
location has led to a large series of approaches and derivations
that, in many cases, have ultimately been workarounds for a bad
idea that have caused their own problems. We've seen
generalizations of URLs to URIs, some of which have worked
better than others. We've seen efforts to accommodate local
characters -- to turn URIs from protocol identifiers to
something more user-friendly -- with IRIs and "short" URLs.
We've seen complex URLs with domains identifying search,
redirection, or charging services and the "real" URL buried in
queries. We've seen several uses for redirection that are
ultimately the result of bad identifiers as well as tricks that
violate the basic DNS design in order to make DNS names
location-dependent. There have been yet other tricks that try
to create adaptive synonyms for names and subtrees. We've seen
at least one model for what URNs are about that sees them as
location-independent identifiers that resolve to
location-specific URLs. We've also seen the development and
growth of other systems, including Handles and the derivative
DOIs, partially because of a perception that the IETF has been
too concerned with the URI model and has therefore fallen down
on the job. In many cases, these approaches and techniques
have been expanded into demonstrations of the adage that every
significant design error creates a business opportunity.
The collection of services that use the DNS to point to
URI-identified resources (NAPTR, U-NAPTR, S-NAPTR, URI) can be
seen as yet another approach to that same set of issues,
potentially a set that allows
DNS-name-lookup -> URI with DNS authority ->
DNS-name-lookup -> NAPTR with multiple URIs, several of
which need to be looked up to determine availability ->
DNS-name-lookup -> URI with DNS authority -> ...
with potentially unlimited recursion depth. Whether that is a
good idea or not (see (2) above), we are developing a rather
large collection of ways to do nearly the same thing, i.e., to
create names that are either location-independent or that can
designate a family of locations. While multiple ways to do the
same thing are sometimes an advantage, they are more often a
source of confusion (and, again, potential bad implementation
behavior and attack vectors). It would be _really_ good to do
some architectural work that would lead to both design and
applicability statements, rather than continuing to add more of
them without an obvious plan.
john