Re: (long/architectural version) Last Call: <draft-faltstrom-uri-10.txt> (The Uniform Resource Identifier (URI) DNS Resource Record) to Proposed Standard

[Mark Andrews <[e-mail]>]

In message <[e-mail]>, John C Klensin writes
:
> 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. 

There is no requirement to use expert review.  The full blown rfc
process is still available.  If you use expert review however the
format of the record is fixed when the review is done.  [ For the
record the format of the record changed which was annoying for those
of us that wrote explict code to handle the type.  The reference
for the type will need to be updated if it hasn't been done. ]

> (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.

Actually they are restricted to using the primary name so that MTA's
can process the MX list without having to lookup any of the target
names.  SMTP is a store-and-forward protocol.  Note: primary name
means the name the machine knows itself as.  This should have address
records.  This allows you to decide what to do with a single MX
lookup with possible fallback lookups for A and AAAA records when
you get back a noerror nodata response to the MX lookup.

Multiple lookups are secondry to this consideration.

SRV has the same restrictions in-case any protocol that wishes to
use it is working in a store-and-forward mode.

> 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
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]                 INTERNET: [e-mail]