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

[John C Klensin <[e-mail]>]

--On Thursday, February 26, 2015 10:59 -0500 Andrew Newton
<[e-mail]> wrote:

> <snipping a lot of text...>
> 
> On Wed, Feb 25, 2015 at 9:16 AM, John C Klensin
> <[e-mail]> wrote:
> 
> 
>> 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.

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

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

> 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