[dnsext] URI RRTYPE review - Comments period end Aug 15th
Frederico A C Neves <fneves@registro.br> Sun, 25 July 2010 18:47 UTC
Return-Path: <owner-namedroppers@ops.ietf.org>
X-Original-To: ietfarch-dnsext-archive@core3.amsl.com
Delivered-To: ietfarch-dnsext-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B104D3A6827; Sun, 25 Jul 2010 11:47:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.957
X-Spam-Level:
X-Spam-Status: No, score=-98.957 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, FRT_BELOW2=2.154, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
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 qaNQnOnwTIv0; Sun, 25 Jul 2010 11:47:14 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9AD703A67F8; Sun, 25 Jul 2010 11:47:14 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from <owner-namedroppers@ops.ietf.org>) id 1Od68a-000Na6-BQ for namedroppers-data0@psg.com; Sun, 25 Jul 2010 18:41:24 +0000
Received: from [2001:12ff:0:2::4] (helo=clone.registro.br) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from <fneves@registro.br>) id 1Od68X-000NZV-0v for namedroppers@ops.ietf.org; Sun, 25 Jul 2010 18:41:21 +0000
Received: by clone.registro.br (Postfix, from userid 1000) id 14B4BE043C; Sun, 25 Jul 2010 15:41:19 -0300 (BRT)
Date: Sun, 25 Jul 2010 15:41:19 -0300
From: Frederico A C Neves <fneves@registro.br>
To: namedroppers@ops.ietf.org
Subject: [dnsext] URI RRTYPE review - Comments period end Aug 15th
Message-ID: <20100725184119.GA42253@registro.br>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
List-ID: <namedroppers.ops.ietf.org>
List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with
List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body.
List-Archive: <http://ops.ietf.org/lists/namedroppers/>
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: 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] URI RRTYPE review - Comments period end … Frederico A C Neves
- Re: [dnsext] URI RRTYPE review - Comments period … Klaus Malorny
- Re: [dnsext] URI RRTYPE review - Comments period … Andrew Sullivan
- Re: [dnsext] URI RRTYPE review - Comments period … Patrik Fältström
- Re: [dnsext] URI RRTYPE review - Comments period … Masataka Ohta
- Re: [dnsext] URI RRTYPE review - Comments period … Phillip Hallam-Baker
- Re: [dnsext] URI RRTYPE review - Comments period … Masataka Ohta
- Re: [dnsext] URI RRTYPE review - Comments period … Florian Weimer
- Re: [dnsext] URI RRTYPE review - Comments period … Patrik Fältström
- Re: [dnsext] URI RRTYPE review - Comments period … Florian Weimer
- Re: [dnsext] URI RRTYPE review - Comments period … Ted Hardie
- Re: [dnsext] URI RRTYPE review - Comments period … Patrik Fältström
- Re: [dnsext] URI RRTYPE review - Comments period … Ted Hardie
- Re: [dnsext] URI RRTYPE review - Comments period … Patrik Fältström
- Re: [dnsext] URI RRTYPE review - Comments period … Patrik Fältström
- Re: [dnsext] URI RRTYPE review - Comments period … Patrik Fältström
- Re: [dnsext] URI RRTYPE review - Comments period … Masataka Ohta
- Re: [dnsext] URI RRTYPE review - Comments period … Patrik Fältström
- Re: [dnsext] URI RRTYPE review - Comments period … Masataka Ohta
- Re: [dnsext] URI RRTYPE review - Comments period … Patrik Fältström
- Re: [dnsext] URI RRTYPE review - Comments period … Phillip Hallam-Baker
- Re: [dnsext] URI RRTYPE review - Comments period … Patrik Faltstrom (pfaltstr)
- Re: [dnsext] URI RRTYPE review - Comments period … Phillip Hallam-Baker
- Re: [dnsext] URI RRTYPE review - Comments period … Phillip Hallam-Baker
- Re: [dnsext] URI RRTYPE review - Comments period … Phillip Hallam-Baker