Re: [dnsext] URI RRTYPE review - Comments period end Aug 15th

[Ted Hardie <[e-mail]>]

Howdy,

I do not think this proposal is quite baked enough.

I would strongly suggest trying this out in private use space as
the primary method of baking, because there are a lot of
potential issues that may turn out to be either imaginary
or un-imagined.

Specifically, I think this template processing should
be delayed on the following grounds from RFc 5395:

3. The documentation of the proposed RRTYPE or RRTYPE(s) is
      incomplete.  (Additional documentation can be provided during the
      public comment period or by the Expert.)

The template notes that the RRTYPE contains a URI, but it does not
give any specific relationship between that URI and domain name at
which it is found.  U-NAPTR and other ways of connecting URIs
and domain names start from a service (or an application), and work
their way to a URI; they start, in other words, from the relationship.

This proposal simply juxtaposes the two, and gives you no way to
formal way to describe what relationship the URI
stands in to the domain name at which it is found.

If there are multiple URIs present at a domain name,
should they be considered alternates?  Is each independent?  Is
this based on internal structures of the data (e.g. the scheme)?  What
does that imply if there has to be truncation in the data returned?
What does it mean if the URI returned is a dns uri?  How about a data
uri?

I suspect that playing in the private use space for a while would show
us that associating a URI with a domain name needs more context
than a simple juxtaposition will allow.  It may be that a meta-type
can do this with specific uri types below it, but I think that the baseline
here is that the URI type by itself will inherently sub-type (minimally by
scheme and possibly by much more).    That needs a lot more design
than this template seems to carry, and if we don't start from that
presumption, I think we'll end up with a useless swamp.

Just my two cents,

Ted


On Sun, Jul 25, 2010 at 11:41 AM, Frederico A C Neves
<[e-mail]> wrote:
> Dear Colleagues,
>
> Bellow is a completed template requesting a new RRTYPE assignment
> under the procedures of RFC5395.
>
> This message starts a 3 weeks period for an expert-review of the DNS
> RRTYPE parameter allocation for URI specified in
> http://tools.ietf.org/html/draft-faltstrom-uri-05
>
> If you have comments on the request, please post them here before Aug
> 15th 18:00 UTC
>
> Best Regards,
> Frederico Neves
>
> --begin 5395 template URI--
> A.   Submission Date:
>
>     May 23, 2009
>
> B.   Submission Type:
>
>     [X] New RRTYPE
>     [ ] Modification to existing RRTYPE
>
> C.   Contact Information for submitter:
>
>     Name: Patrik Faltstrom
>     Email Address: [e-mail]
>     International telephone number: [phone]
>     Other contact handles:
>     (Note: This information will be publicly posted.)
>
> D.   Motivation for the new RRTYPE application?
>
>     There is no easy way to get from a domain name to a URI.  Some
>     mechanisms exists via use of the NAPTR [RFC3403] resource
>     record.  That implies quite complicated rules that are
>     simplified via the S-NAPTR [RFC3958] specification.  But, the
>     ability to directly look up a URI still exists.  This
>     specification uses a prefix based naming mechanism originated in
>     the definition of the SRV [RFC2782] resource record, and the
>     RDATA is a URI, encoded as one text field.
>
>     See also Section 1 in draft-faltstrom-uri-05.txt.
>
> E.   Description of the proposed RR type.
>
>     The format of the URI resource record is as follows:
>
>
>     Ownername TTL Class URI Priority Weight Target
>
>
>     The URI RR has service information encoded in its ownername.  In
>     order to encode the service for a specific owner name one uses
>     service parameters.  Valid service parameters used are either
>     Enumservice Registrations registered by IANA, or prefixes used
>     for the SRV resource record.
>
>     The wire format of the RDATA is as follows:
>
>
>                         1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |          Priority             |          Weight               |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    /                                                               /
>    /                             Target                            /
>    /                                                               /
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
> F.   What existing RRTYPE or RRTYPEs come closest to filling that
>     need and why are they unsatisfactory?
>
>     The RRTYPE that come closest is the NAPTR resource record.  It
>     is for example used in the DDDS and S-NAPTR algorithms.  The
>     main problem with the NAPTR is that selection of what record (or
>     records) one is interested in is based on data stored in the
>     RDATA portion of the NAPTR resource record.  This, as explained
>     in RFC 5507 [RFC5507], is not optimal for DNS lookups.  Further,
>     most applications using NAPTR resource records uses regular
>     expression based rewrite rules for creation of the URI, and that
>     has shown be complicated to implement.
>
>     The second closest RRTYPE is the SRV record that given a
>     prefixed based naming just like is suggested for the URI
>     resource record, one get back a port number and domain name.
>     This can also be used for creation of a URI, but, only URIs
>     without path components.
>
> G.   What mnemonic is requested for the new RRTYPE (optional)?
>
>     URI
>
> H.   Does the requested RRTYPE make use of any existing IANA Registry
>     or require the creation of a new IANA sub-registry in DNS
>     Parameters?
>
>     Yes, partially.
>
>     One of the mechanisms to select a service is to use the
>     Enumservice Registry managed by IANA.  Another is to use
>     services and protocols used for SRV records.
>
> I.   Does the proposal require/expect any changes in DNS servers/
>     resolvers that prevent the new type from being processed as an
>     unknown RRTYPE (see [RFC3597])?
>
>     No
>
> J.   Comments:
>
>     None
> --end 5395 template URI--
>
>