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

From: John C Klensin <[email-masked]>
Date: Wed, 25 Feb 2015 09:16:18 -0500

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

---

From: Mark Andrews <[email-masked]>
Date: Thu, 26 Feb 2015 10:14:03 +1100

In message <[email-masked]>, John C Klensin writes
> alternative to expert review for specs that people will want on

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

> 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
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Andrew Newton <[email-masked]>
Date: Thu, 26 Feb 2015 10:59:09 -0500

<snipping a lot of text...>

On Wed, Feb 25, 2015 at 9:16 AM, John C Klensin <[email-masked]> wrote:

> If (as I believe to be the case) the main
> at least some instances of some of those, out.

I was unaware that there was a need for only one way to do this. It seems
to me that the multiple methods could co-exist without collision. While I
agree with your observations about these methods, I do not like the idea of
the IETF mandating single solutions unnecessarily (in its specifications).

>   If, instead,

I'm confused. How can we know a better idea will come along until it has
actually surfaced?

> While multiple ways to do the

I agree with a lot of things you have written here. But I'm wary of any
effort regarding a grand unifying architecture, if that is where such an
effort takes us... especially given the recent discussions on URIs/URNs.
That said, there may be room for some discussion here as there are other
ideas in this space (https://datatracker.ietf.org/doc/draft-newton-link-rr/
).

-andy

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 26 Feb 2015 15:57:36 +0100

> On 26 Feb 2015, at 00:14, Mark Andrews <[email-masked]> wrote:
> 

I think there are a number of things we have problems with in the IETF. Like cross-area-review and because of this design. Each area look at things from their perspective and hold hard to their ideas on the future of the world.

In this specific case, sure, like many other definitions by IETF it was not optimal when the review happened, but maybe it is wrong to have the later published RFC on standards track as it seems to end up? Maybe it should be "just" informational (if that matters).

Regarding the change that Mark point out in this case, the clarification that was made from an earlier draft to what we now have have are I claim not incompatible with what is in the application for an RRType that was applied for. The difference is that we now clarify that the URI is "just bytes" to the end of the RDATA field. It is not an (as defined in DNS) text string which has limited length. I.e. we all remember a TXT RRType can have multiple text strings in the RDATA field.

This clarification was made in cooperation and in coordination with people that implement URI (which was when this was discovered).

At least that is what I think you do talk about Mark?

   Patrik

---

From: John C Klensin <[email-masked]>
Date: Thu, 26 Feb 2015 12:37:45 -0500

> I was unaware that there was a need for only one way to do
> this. It seems to me that the multiple methods could co-exist
> without collision. While I agree with your observations about
> these methods, I do not like the idea of the IETF mandating
> single solutions unnecessarily (in its specifications).

Let me be a bit more clear.  I don't see a need to "mandate a
single solution".    On the other hand, suppose we say "X is the
standard way to do A", and then say "Y is the standard way to do
A", and then say "Z is the standard way to do A".  Unless we
have suddenly started liking interoperability and operational
problems (noting that, at least absent a lot of additional
processing that would disqualify the registration, there is no
way to ask the DNS for all of the records, RTYPE-independent,
that are associated with a parent node and that have URIs in
their DATA), it seems to me there is some obligation to offer
guidance as to what should be used when.  If that guidance is
simply "just pick whatever appeals to you", I'm probably ok with
that as long as we are explicit about it, but I don't think the
issue of multiple RRTYPEs that do almost the same thing can be
ignored.

Especially given your LINK proposal, I'd find it equally
reasonable to see a statement in the present doc that said
"despite given the very general name 'URI', this RRTYPE is
really designed for ENUM and things that are like it, while LINK
may be more appropriate for use with the web and HTTP URLs in
particular".   Such a statement could also include more of a
discussion about the difference between a normally-named node
(e.g., "example.com") and a service-designation node (e.g.,
"_foo._bar.example.com") and their applicability.  My objection
in this area is not that we've specified more than one way to do
similar things; it is that we are leaving the reader guessing as
to how they might decide what to use and doing so without being
explicit about that.

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

> I'm confused. How can we know a better idea will come along
> until it has actually surfaced?

We probably can't.  But, after more than three variations on the
same theme, it seems to me to be reasonable to ask authors if
they have reason to believe that they've actually got it right
this time or if implementers should expect yet another variation
in a year or so and to get that written down.... and to get
their answers on the record.

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

> I agree with a lot of things you have written here. But I'm
> wary of any effort regarding a grand unifying architecture, if
> that is where such an effort takes us... especially given the
> recent discussions on URIs/URNs. That said, there may be room
> for some discussion here as there are other ideas in this
> space (https://datatracker.ietf.org/doc/draft-newton-link-rr/
> ).

Precisely.   I also note that, assuming that draft can be
believed, it is asking for standards track but is not associated
with a registration that has been made already and so doesn't
get us into the "you should standardize this but don't have
change control even pre-approval" situation.

As to "grand unifying architecture", I'm probably going to get
myself attacked from both sides for saying this but it appears
to me that we have two grand unifying architectures in this
space (DNS and URI) and they are both showing signs of being
problematic (if not actually broken) for purposes to which
people want to put them.

best,
    john

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 28 Feb 2015 01:36:34 +0000

> and mechanism.  If it isn't, then this document should explain

No, it is an alternative. And we need an alternative.

I do not like the NAPTR proposal. I have never liked it and would like to
deprecate it as historic because I find it confused and overly complex.

In my view, NAPTR breaks a core architectural principle that DNS text
labels have no structure. I find the matching rules to be a hack and not a
nice one.

But under the new RR allocation scheme, we are merely proposing new
records, not deleting old ones.

> potential attack vectors waiting to be discovered and exploited.

Again, I agree with this, but I don't see the relationship to URI.

This is because URI is trying to solve a problem that NAPTR has never been
a solution for. Even if the authors thought differently.

ENUM is arguably an area where cruft was needed. But at this point the only
thing to do with the telephone system is plan for a graceful termination of
service along with the telegram and telex. Any technology required by enum
should be limited to enum.

> nor does it make recommendations as to when one or the other

No, it is defining a Web Service discovery mechanism that allows the
location of the Web Service end point to be specified.

But is it really necessary?

We could use SRV and the existing .well-known services registry. All we
need to do is to define a default SRV prefix. So if the .well-known label
is 'myservice' we would use something like

_myservice._wks.example.com SRV 0 0 443 host1.example.net

https://host1.example.net/.well-known/myservice/

All we are getting from URI is the ability to point the web service
endpoint at any place in the Web site.

---

From: John C Klensin <[email-masked]>
Date: Fri, 27 Feb 2015 23:06:59 -0500

Commenting on one thing only (I disagree with some of your other
comments but, given Pete's note, I don't see it as being useful
to debate them at this point)...

--On Saturday, February 28, 2015 01:36 +0000 Phillip
Hallam-Baker <[email-masked]> wrote:

>...
> So if the .well-known label

> All we are getting from URI is the ability to point the web
> service endpoint at any place in the Web site.

And, if nothing else, the ability to use URI schemes other than
https.  I think that is rather important; YMMD.
draft-falstrom-uri says "URI", not "web" or "http" or "https"
and the difference is significant.

    john