Re: [dnsext] [Technical Errata Reported] RFC3363 (3220)

Brian Haberman <brian@innovationslab.net> Thu, 10 May 2012 12:50 UTC

Return-Path: <brian@innovationslab.net>
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7376121F86A0 for <dnsext@ietfa.amsl.com>; Thu, 10 May 2012 05:50:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ywGKVlQnlXT1 for <dnsext@ietfa.amsl.com>; Thu, 10 May 2012 05:50:39 -0700 (PDT)
Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id D596821F869A for <dnsext@ietf.org>; Thu, 10 May 2012 05:50:39 -0700 (PDT)
Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id BB3AC88183; Thu, 10 May 2012 05:50:39 -0700 (PDT)
Received: from clemson.local (nat-gwifi.jhuapl.edu [128.244.87.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 1B346140039; Thu, 10 May 2012 05:50:39 -0700 (PDT)
Message-ID: <4FABB9A0.6050307@innovationslab.net>
Date: Thu, 10 May 2012 08:50:40 -0400
From: Brian Haberman <brian@innovationslab.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: cet1@cam.ac.uk
References: <20120509214500.0ED1862180@rfc-editor.org> <Prayer.1.3.4.1205092315220.29217@hermes-2.csi.cam.ac.uk>
In-Reply-To: <Prayer.1.3.4.1205092315220.29217@hermes-2.csi.cam.ac.uk>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Thu, 10 May 2012 06:27:53 -0700
Cc: "rfc-editor@rfc-editor.org >> RFC Errata System" <rfc-editor@rfc-editor.org>, rdroms.ietf@gmail.com, ogud@ogud.com, dnsext@ietf.org
Subject: Re: [dnsext] [Technical Errata Reported] RFC3363 (3220)
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 10 May 2012 12:50:40 -0000

Chris,
      This errata report came out of the processing of 
draft-ietf-dnsext-rfc2672bis-dname.  That draft contains text in section 
4 that states:

    The DNAME RR is discussed in RFC 3363, section 4, on A6 and DNAME.
    The opening premise of this section is demonstrably wrong, and so the
    conclusion based on that premise is wrong.

The RFC Editor asked if there should be an errata report filed to clean 
up RFC 3363.

Regards,
Brian

On 5/9/12 6:15 PM, Chris Thompson wrote:
> On May 9 2012, RFC Errata System wrote:
>
>> The following errata report has been submitted for RFC3363,
>> "Representing Internet Protocol version 6 (IPv6) Addresses in the
>> Domain Name System (DNS)".
>>
>> --------------------------------------
>> You may review the report below and at:
>> http://www.rfc-editor.org/errata_search.php?rfc=3363&eid=3220
>>
>> --------------------------------------
>> Type: Technical
>> Reported by: Mark Andrews <marka@isc.org>
>>
>> Section: 4
>>
>> Original Text
>> -------------
>> 4. DNAME in IPv6 Reverse Tree
>>
>> The issues for DNAME in the reverse mapping tree appears to be
>> closely tied to the need to use fragmented A6 in the main tree: if
>> one is necessary, so is the other, and if one isn't necessary, the
>> other isn't either. Therefore, in moving RFC 2874 to experimental,
>> the intent of this document is that use of DNAME RRs in the reverse
>> tree be deprecated.
>>
>>
>> Corrected Text
>> --------------
>> 4. DNAME in IPv6 Reverse Tree
>>
>> [Deleted due to faulty premise.]
>>
>> Notes
>> -----
>> The opening premise of this section is demonstrably wrong, and so the
>> conclusion based on that premise is wrong. The use of DNAME in the
>> reverse tree is and always has been independent of A6.
>>
>> Instructions:
>> -------------
>> This errata is currently posted as "Reported". If necessary, please
>> use "Reply All" to discuss whether it should be verified or
>> rejected. When a decision is reached, the verifying party (IESG)
>> can log in to change the status and edit the report, if necessary.
>> --------------------------------------
>> RFC3363 (draft-ietf-dnsext-ipv6-addresses-02)
>> --------------------------------------
>> Title : Representing Internet Protocol version 6 (IPv6) Addresses in
>> the Domain Name System (DNS)
>> Publication Date : August 2002
>> Author(s) : R. Bush, A. Durand, B. Fink, O. Gudmundsson, T. Hain
>> Category : INFORMATIONAL
>> Source : DNS Extensions
>> Area : Internet
>> Stream : IETF
>> Verifying Party : IESG
>> _______________________________________________
>> dnsext mailing list
>> dnsext@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsext
>
> I don't really know whether this is technically an erratum, but it was a
> quite unnecessary and unjustified side-swipe at DNAME.
>
> As it happens, our primary use of DNAME is in the IPv4 reverse tree rather
> than the IPv6 one (the wording in RFC 3363 is slithery in at least half-
> implying that ought to be deprecated as well), because its primary use
> (or that of CNAME, for that matter) is consolidation, and at this time
> IPv4 space is much more fragmented.
>