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
- [dnsext] WGLC: RFC6195bis IANA guidance Olafur Gudmundsson
- Re: [dnsext] WGLC: RFC6195bis IANA guidance Michael Sheldon
- Re: [dnsext] WGLC: RFC6195bis IANA guidance Alfred Hönes
- Re: [dnsext] WGLC: RFC6195bis IANA guidance Dick Franks
- Re: [dnsext] WGLC: RFC6195bis IANA guidance Donald Eastlake
- Re: [dnsext] WGLC: RFC6195bis IANA guidance Donald Eastlake
- Re: [dnsext] WGLC: RFC6195bis IANA guidance Olafur Gudmundsson
- Re: [dnsext] WGLC: RFC6195bis IANA guidance Alfred Hönes
- Re: [dnsext] WGLC: RFC6195bis IANA guidance Donald Eastlake
- [dnsext] WGLC: RFC6195bis IANA guidance Donald Eastlake
- Re: [dnsext] WGLC: RFC6195bis IANA guidance Ray Bellis
- Re: [dnsext] WGLC: RFC6195bis IANA guidance Donald Eastlake
- Re: [dnsext] WGLC: RFC6195bis IANA guidance Mark Andrews
- Re: [dnsext] WGLC: RFC6195bis IANA guidance Paul Hoffman
- Re: [dnsext] WGLC: RFC6195bis IANA guidance Nicholas Weaver
- Re: [dnsext] WGLC: RFC6195bis IANA guidance Donald Eastlake
- Re: [dnsext] WGLC: RFC6195bis IANA guidance Paul Hoffman
- Re: [dnsext] WGLC: RFC6195bis IANA guidance Dick Franks
- Re: [dnsext] WGLC: RFC6195bis IANA guidance Donald Eastlake
- Re: [dnsext] WGLC: RFC6195bis IANA guidance Donald Eastlake
- Re: [dnsext] WGLC: RFC6195bis IANA guidance Andrew Sullivan
- Re: [dnsext] WGLC: RFC6195bis IANA guidance Michael Sheldon
- Re: [dnsext] WGLC: RFC6195bis IANA guidance Mark Andrews
- Re: [dnsext] WGLC: RFC6195bis IANA guidance Paul Hoffman
- Re: [dnsext] WGLC: RFC6195bis IANA guidance Chris Thompson
- Re: [dnsext] WGLC: RFC6195bis IANA guidance Donald Eastlake