Re: [dnsext] URI RRTYPE review - Result [IANA #376037]

Frederico A C Neves <fneves@registro.br> Thu, 17 February 2011 23:16 UTC

Return-Path: <fneves@registro.br>
X-Original-To: dnsext@core3.amsl.com
Delivered-To: dnsext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBA503A6CC3 for <dnsext@core3.amsl.com>; Thu, 17 Feb 2011 15:16:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.446
X-Spam-Level:
X-Spam-Status: No, score=-0.446 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_BELOW2=2.154, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wPKX6INBaTqL for <dnsext@core3.amsl.com>; Thu, 17 Feb 2011 15:16:08 -0800 (PST)
Received: from clone.registro.br (clone.registro.br [IPv6:2001:12ff:0:2::4]) by core3.amsl.com (Postfix) with ESMTP id 0621D3A6CEC for <dnsext@ietf.org>; Thu, 17 Feb 2011 15:16:08 -0800 (PST)
Received: by clone.registro.br (Postfix, from userid 1000) id 5BF06E0457; Thu, 17 Feb 2011 21:16:38 -0200 (BRST)
Date: Thu, 17 Feb 2011 21:16:38 -0200
From: Frederico A C Neves <fneves@registro.br>
To: dnsext@ietf.org
Message-ID: <20110217231638.GA42567@registro.br>
References: <20110127134320.GC91248@registro.br>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20110127134320.GC91248@registro.br>
Cc: iana-prot-param@iana.org
Subject: Re: [dnsext] URI RRTYPE review - Result [IANA #376037]
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsext>
List-Post: <mailto:dnsext@ietf.org>
List-Help: <mailto:dnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Feb 2011 23:16:09 -0000

Dear Colleagues,

This message ends the review process for the URI RRTYPE, according to
my judgment it meets both requirements of section 3.1.1 and none of
section 3.1.2 of RFC5395 and should be accepted.

Best Regards,
Frederico Neves

On Thu, Jan 27, 2011 at 11:43:20AM -0200, Frederico A C Neves wrote:
> Dear Colleagues,
> 
> Bellow is a resubmission of 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 any new comments regarding this request that have not yet
> being made at the thread starting with message
> http://www.ietf.org/mail-archive/web/dnsext/current/msg08956.html ,
> please post them here before Feb 17th 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: paf@cisco.com
>      International telephone number: +46-8-6859131
>      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--
> _______________________________________________
> dnsext mailing list
> dnsext@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsext