Re: [dnsext] WGLC: RFC6195bis IANA guidance

Mark Andrews <marka@isc.org> Tue, 03 July 2012 14:14 UTC

Return-Path: <marka@isc.org>
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 EC87621F8823 for <dnsext@ietfa.amsl.com>; Tue, 3 Jul 2012 07:14:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.883
X-Spam-Level:
X-Spam-Status: No, score=-1.883 tagged_above=-999 required=5 tests=[AWL=0.716, BAYES_00=-2.599]
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 Xf6X3xZxIBC9 for <dnsext@ietfa.amsl.com>; Tue, 3 Jul 2012 07:13:42 -0700 (PDT)
Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 2C68421F8754 for <dnsext@ietf.org>; Tue, 3 Jul 2012 07:13:42 -0700 (PDT)
Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 788705F984C; Tue, 3 Jul 2012 14:13:37 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (CPE-124-177-138-97.lns3.woo.bigpond.net.au [124.177.138.97]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 4CCC5216C33; Tue, 3 Jul 2012 14:13:35 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 45D4D222DC10; Wed, 4 Jul 2012 00:13:31 +1000 (EST)
To: Donald Eastlake <d3e3e3@gmail.com>
From: Mark Andrews <marka@isc.org>
References: <20120613090016.205a61dff9fc1684c258b274662bb912.d2ce8b95d9.wbe@email00.secureserver.net> <CAF4+nEGbZavii4p_km2kRik-5B2RB19wJ2TFZJ-tSbX-x=Nh6A@mail.gmail.com> <CAF4+nEHdtq2dRknB8NEasfz7THUOfpPaE7Qr189CjQpZVt5D2w@mail.gmail.com>
In-reply-to: Your message of "Mon, 02 Jul 2012 10:22:14 -0400." <CAF4+nEHdtq2dRknB8NEasfz7THUOfpPaE7Qr189CjQpZVt5D2w@mail.gmail.com>
Date: Wed, 04 Jul 2012 00:13:31 +1000
Message-Id: <20120703141331.45D4D222DC10@drugs.dv.isc.org>
Cc: IETF DNSEXT WG <dnsext@ietf.org>
Subject: Re: [dnsext] WGLC: RFC6195bis IANA guidance
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: Tue, 03 Jul 2012 14:14:04 -0000

In message <CAF4+nEHdtq2dRknB8NEasfz7THUOfpPaE7Qr189CjQpZVt5D2w@mail.gmail.com>, Donald Ea
stlake writes:
> [cc'ed to DNSEXT with permission]
> 
> Hi Mark,
> 
> Thanks for the comments. Stuff in curly braces ("{ }") is stuff I've added.
> 
> On Thu, Jun 28, 2012 at 11:04 PM, Mark Andrews <marka@isc.org> wrote:
> >
> >   {existing draft:}
> >    The AA, TC, RD, RA, AD, and CD bits are each theoretically meaningful
> >    only in queries or only in responses, depending on the bit. However,
> >    some DNS implementations copy the query header as the initial value
> >    of the response header without clearing bits. Thus, any attempt to
> >    use a "query" bit with a different meaning in a response or to define
> >    a query meaning for a "response" bit is dangerous, given existing
> >    implementation. Such meanings may only be assigned by a Standards
> >    Action.
> >
> >   {proposed:}
> >    The AA, TC, RD, RA, AD[1], and CD bits are each theoretically meaningful
> >    only in queries or only in responses, depending on the bit.  Only
> >    RD and CD are expected to be copied from the query to the response
> >    however some DNS implementations copy all the query header as the
> >    initial value of the response header.  Thus, any attempt to
> >    use a "query" bit with a different meaning in a response or to define
> >    a query meaning for a "response" bit is dangerous, given existing
> >    implementation. Such meanings may only be assigned by a Standards
> >    Action.
> >
> >    [1] AD is expected to have seperate but related meanings in both the
> >    query and response.
> 
> OK. I don't have a problem with the proposed text except that I'd like
> to know where the expectation that AD has a meaning in queries comes
> from...
> 
> >    2.2 OpCode Assignment
> >
> >    Status is reserved in RFC 1035 but not behaviour is defined.
> 
> OK. I can add "Although the Status OpCode is reserved in [RFC1035],
> its behavior has not been specified."
> 
> >    2.3 RCODE Assignment
> >
> >         NOTAUTH is also overloaded and you need to look at the TSIG
> >         result code to work out which.   If the TSIG result code
> >         is zero or does not exist then it is not authoritative.
> >
> >         "Not authoritative"     [RFC 2136]
> >         "Not authorised"        [RFC 2845]
> 
> OK. I can change the table entry to point to a note right after the
> RCODE table saying that.
> 
> >    RRTYPE assignments need to say something about the rdata format
> >    no longer being subject to change.  Its not for reserving a code
> >    point as it will be coded into implementations.

DANE thought that they had a code point that they could change the
internal structure about at will by going through the allocation
process.  They needed to be disavowed of this notion.  This should
not happen again.

> I'm not quite certain what you mean above. That the RDATA format
> approved as part of the RRTYPE assignment process can never be changed
> later? Seems reasonable that it can't be changed unilaterally. But I
> don't see why you shouldn't be able to change it by going through the
> process again.

Because once you have code in the field that knows the internal
structure of a RR changing that structure breaks those implementations
that have implemented the RR. 

> Maybe there is some field or value or flag or something
> that is just wrong or can't possibly work or whatever that wasn't
> spotted when the application was initially processed. Or maybe even
> for problems not that bad. Of course, you could always get another
> RRTYPE but that has problems as well, with having to query both, etc.
> There are various engineering trade offs so I don't think a flat
> prohibition on any changes, if that is what you are saying, is
> reasonable. Question B.1 on the RRTYPE Application temple already asks
> if it is a new assignment or a modification of a previously assigned
> RRTYPE.
> 
> Thanks,
> Donald
> =============================
>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>  155 Beaver Street, Milford, MA 01757 USA
>  d3e3e3@gmail.com
> 
> > --
> > Mark Andrews, ISC
> > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org