On 28 jan 2015, at 08:12, Mark Nottingham <mnot(_at_)mnot(_dot_)net> wrote:
IESG / Patrik,
First of all - I think it's interesting to carry URIs in DNS. However, I have
a few concerns about the document that I'd like to work through.
Mark, thanks for these comments. Let me try to address them, but first some
history.
The first version of this draft was posted as draft-ietf-enum-uri-00.txt on
March 31 2007. In those days the ENUM wg did discuss a revision of the ENUM RFC
and did look at using this URI RRType instead of the (to me personally much
more complicated) NAPTR construction. The consensus in the wg was to NOT go
down the path of URI RRType.
After this, the draft left the ENUM wg and turned into draft-faltstrom-uri
series. A long discussion did take place in various DNS working groups, in
parallell with the new process for registration of RRTypes (that did not need
RFCs anymore). Slight confusion over what path to take, RFC or RRType
registration lead to the RRType be registered, which the URI RR is, with number
256 on 2011-02-22.
This draft should because of this TODAY maybe be informational and not
proposed, but that "stuck" from the early days of processing the draft.
The draft has been discussed several times on many mailing lists, and I do
never think we will reach full consensus, to be honest, as I have never seen
anything related to DNS reach anything better than rough consensus ;-) New
issues get added every day... And old ones come back!
So, with that as a background, here are my comments.
## The ENUM service registry
The document effectively gives a "type" for the URI by associating a value
from the ENUM service registry. While that makes sense from the standpoint of
ENUM, if this mechanism is truly generic to *all* URIs, it seems to me that
it'd be much more sensible to use the typing system already in place for URIs
-- link relations <http://tools.ietf.org/html/rfc5988>.
As it is, I think this proposal is going to surprise a lot of people very
unpleasantly, when they find that URIs have effectively become subservient to
ENUM, at least within the confines of DNS.
This could be addressed by either using link relations (although I realise
that would require a fair amount of work), or by renaming the RR to
"ENUM_URI" or similar, along with appropriate changes in the text (i.e., this
is a record specific to ENUM, not generic to all URIs in DNS).
The RRType is registered and can not be changed.
That said, what can be referred to is a "better" registry for services. IETF do
not have a registry for services for SRV. If IETF did, then I would have
referenced that registry. I think it is "stupid" to create a new registry. This
draft refer to the ENUM Service Registry. For SRV no real registry exists, but
the DNS-SD people have this: <http://www.dns-sd.org/servicetypes.html>
## The "home page" example
Section 6 uses a "home page" lookup as the only example application for this
RR. To my knowledge, no Web browser does this or is considering doing so, and
moreover, pretty much any Web stack person would be extremely surprised by
both this.
Do you have any implementations of this use case, or prospect for them? Have
you talked to Web security folks about the implications of doing so?
I am working within the libcurl community to look at support for URI resource
record types and others.
I have questions from various developers that want to use URI, but you are
correct that they are not "web browsers". They are more "people that use HTTP
for transport for data used for their service".
I agree that with that as a background a different example might make that more
clear, although it might be harder to understand.
Is your suggestion to add more examples? I think that is a fair request that
makes lot of sense.
## Alternative approaches
In Appendix A (D), the original allocation request says:
"""
There is no easy way to get from a domain name to a URI (or IRI).
"""
That's not actually true any more; we now have Well-Known URIs
<https://tools.ietf.org/html/rfc5785>, which allows an application to define
how to get a URI from a bare hostname. While it's true that it's currently a
little more expensive than DNS (requiring a TCP connection for the time
being), we do have substantial deployment experience with it, and it seems to
be operationally much simpler, as compared to adding a new DNS record.
Are there use cases where .well-known isn't workable, as compared to this RR?
Yes, when the namespace of the web server is not under control by the parties
running services (i.e. they are given URIs).
And on top of that you have already pointed at the issue with lookups in DNS
compared to the HTTP transport, where also lots of redirects are common,
specifically in CDNs, virtual hosting (www.example.com / example.com is a
trivial example of course) etc.
But you also point at a for the IETF sensible issue. When the well known URI
was discussed, I did present the URI RRType (and SRV, and NAPTR and...) but as
too often happens "the web community" responded with "we can only look up A
records". So the use of more efficient mixes of DNS and HTTP to reach the for
the user best experience was never really discussed. Not there, not then, not
before and not after. :-(
The problem NOW on the table though is to get an RFC that describes the already
existing RRType URI.
Patrik
Cheers,
On 28 Jan 2015, at 9:38 am, The IESG <iesg-secretary(_at_)ietf(_dot_)org>
wrote:
The IESG has received a request from an individual submitter to consider
the following document:
- 'The Uniform Resource Identifier (URI) DNS Resource Record'
<draft-faltstrom-uri-10.txt> as Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf(_at_)ietf(_dot_)org mailing lists by 2015-02-24. Exceptionally,
comments may be
sent to iesg(_at_)ietf(_dot_)org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.
Abstract
This document defines a new DNS resource record, called the Uniform
Resource Identifier (URI) RR, for publishing mappings from hostnames
to URIs.
This document updates RFC 3404 and RFC 3958.
The file can be obtained via
http://datatracker.ietf.org/doc/draft-faltstrom-uri/
IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-faltstrom-uri/ballot/
No IPR declarations have been submitted directly on this I-D.
--
Mark Nottingham https://www.mnot.net/
signature.asc
Description: Message signed with OpenPGP using GPGMail