Re: [dnsext] WGLC: RFC6195bis IANA guidance
Donald Eastlake <d3e3e3@gmail.com> Fri, 29 June 2012 02:16 UTC
Return-Path: <d3e3e3@gmail.com>
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 5022411E8113 for <dnsext@ietfa.amsl.com>; Thu, 28 Jun 2012 19:16:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.361
X-Spam-Level:
X-Spam-Status: No, score=-103.361 tagged_above=-999 required=5 tests=[AWL=-0.062, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, 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 oztoJJK+zGg5 for <dnsext@ietfa.amsl.com>; Thu, 28 Jun 2012 19:16:32 -0700 (PDT)
Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3640011E80FA for <dnsext@ietf.org>; Thu, 28 Jun 2012 19:16:32 -0700 (PDT)
Received: by ghbg16 with SMTP id g16so2643726ghb.31 for <dnsext@ietf.org>; Thu, 28 Jun 2012 19:16:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=TRfn048hZOB1aCaKRFcfxDIFeilG4gjO74QV/LY0FSc=; b=E+6fP7pd8g36rY+ZfaLjiimkxMEY54bPQB+ky+CArA4ZrpbTnsKWM+yDN8eCGONmAP eb4UL73QSG/LKIv2A6qVjmkX+NpoMdr6/WsPMjBGLVY1ju2+a/Z36gcObBQgF0lwhul/ PxwgCiexMoaxhgBAhDM8ZbCGuODb2oUXAKLTuWr9+yByID58UNTe7o7CDtsxqqXTTWHI V7DQyTCkY3VSeqLftlAJF+cW/dk9g8W+HJx44meKjaEX6lOS7VP1KctnKvdbgCy29cGq vKIHVXdzsi1WiwY3R3GCctWswtZptSmneasfzmv4mjCK91uc2vZzLsR8+Fm7Ki+QDuRv TJJg==
Received: by 10.50.213.106 with SMTP id nr10mr243208igc.58.1340936191250; Thu, 28 Jun 2012 19:16:31 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.16.227 with HTTP; Thu, 28 Jun 2012 19:16:10 -0700 (PDT)
In-Reply-To: <201206141304.PAA00956@TR-Sys.de>
References: <201206141304.PAA00956@TR-Sys.de>
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Thu, 28 Jun 2012 22:16:10 -0400
Message-ID: <CAF4+nEG5L+OQ4qVwSf2q5UdmrZH1aYnVgSVLUW+C7s+yk6XAKg@mail.gmail.com>
To: Alfred HÎnes <ah@tr-sys.de>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: dnsext@ietf.org, ogud@ogud.com
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: Fri, 29 Jun 2012 02:16:33 -0000
Hi Alfred, On Thu, Jun 14, 2012 at 9:04 AM, Alfred HÎnes <ah@tr-sys.de> wrote: > ... > > (1) Section 3.1.4 and/or Appendix B > > Maybe the IESG will call for a citation for closing the AFSDB > sub-registry. RFC 5864 is the proper reference (and its author has > approved the formal closing after checking with the AFS community). Adding such a reference seems reasonable. I suggest that, just before the last sentence of the first paragraph in Section 3.1.4, adding "Use of the AFSDB RR to locate AFS cell database servers was deprecated by [RFC5864]." and noting this addition in Appendix B. > (2) Section 3.2 > > In the RCODE registry (Section 2.3), there is an apparent > overloading of RCODE=16: > BADVERS (RFC 2671 / RFC 2671bis) vs. BADSIG (RFC 2845). Yes. But it seems unlikely to cause a problem as one is only used in OPT and one s only used in TSIG. > Looking back into RFC 2845, it seems that the clerical error > has happened at IANA when acting upon the assignments in that RFC. > The second paragraph of Section 7 of RFC 2845 (on top of page 13) > clearly states: > > ! IANA is expected to create and maintain a registry of "TSIG Error > ! values" to be used for "Error" values as defined in section 2.3. > ! Initial values should be those defined in section 1.7. New TSIG > ! error codes for the TSIG error field are assigned using the IETF > ! Consensus policy defined in RFC 2434. > > Note that the TSIG Error field is a component of TSIG RDATA distinct > from the RCODE field in the DNS message header and its extension in > OPT RRs. An According to RFC 2845 (which seems to be mostly unaware > of EDNS, besides references to binary labels), there is an intentional > semantical overlap for Error values 0..15, which are specified as being > identical with the non-extended RCODES (0..15) in sect. 1.7 of RFC 2845; > the "new" TSIG Error values 16..18 are to be signaled together with > RCODE = NotAuth(9) (originally specified in RFC 2136). > The idea there obviously was to make TSIG independent of the OPT RR, > i.e. to allow TSIG without EDNS, but to this end RFC 2845 likely better > had accomodated the extended RCODE BADVERS(16) assigned by RFC 2671 and > chosen Error values 17..19 for TSIG purposes. Of course, your quote from the IANA Considerations of RFC 2845 (TSG) is correct; however, I do not think the evidence is all on your side. In particular, earlier in RFC 2845, the error field is described as an "expanded RCODE". This is essentially the same term that RFC 2671 (OPT) uses ("an extended RCODE") and the same term that RFC 2930 (TKEY) uses ("The error code field is an extended RCODE."). > However, IANA obviously has registered the actual new values 16..18 > in the RCODE registry and _not_ established a TSIG Error code registry. > Mistakes happen, and it also may be wise to have RCODE values 17 and 18 > "reserved" so that additional overloading cannot arise in the future. > > But IMO it would be worth adding "[*]" to the three RCODE registry > entries based on RFC 2845: BADSIG, BADKEY, and BADTIME, e.g.: > > 16 BADSIG TSIG Signature Failure [*] [RFC2845] > 17 BADKEY Key not recognized [*] [RFC2845] > 18 BADTIME Signature out of time window [*] [RFC2845] > > ... and to add a footnote to the rigistry that says (e.g.): > > [*] These values are only to be used in the Error field of TSIG RRs; > they cannot appear in the (extended) RCODE field of OPT RRs. > > Also, for added precision and consistency with RFC 2845 and RFC 2930, > the last clause in the first paragraph of Section 2.3 should perhaps > be adjusted as follows: > > OLD: > and the TSIG and TKEY RRs have a 16-bit RCODE field. > ^^^^^ > NEW: > and the TSIG and TKEY RRs have a 16-bit Error field. > ^^^^^ I believe that the more different DNS error registries there are, the more confusion and the more future errors in assignment will occur. Except for the values of the 4-bit DNS header un-extended RCODE, for which precious few free values exist, there is an abundance of values available, so there is no scarcity reason for separate registries with potentially overlapping values. It is also the case that a single unified number space for DNS errors has been presented for years in RFC 6195, RFC 5395, and RFC 2929 for use in the unextended DNS header, the OPT extended DNS header, the TSIG RR error field, and the TKEY error field. In all these years, no one has had a problem with there being a single, unified DNS error number space. So, to the extent that there is any consensus among these document I believe it is for the simpler model of a single number space. To the extent that there s any ambiguity here, I would prefer to resolve it by adding text to Section 2.3 of the rfc6195bis draft like the following: "To the extent that any prior RFCs imply any sort of different error number space for the OPT, TSIG, or TKEY RRs, they are superseded by this unified DNS error number space. With the existing exception of error number 16, the same error number MUST NOT be assigned for different errors even if they would occur in different RR types." Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com > Kind regards, > Alfred. > > -- > > +------------------------+--------------------------------------------+ > | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | > | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | > | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | > +------------------------+--------------------------------------------+ >
- [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