Re: [dnsext] WGLC: RFC6195bis IANA guidance

Alfred Hönes <ah@TR-Sys.de> Thu, 14 June 2012 13:06 UTC

Return-Path: <A.Hoenes@TR-Sys.de>
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 F04FD21F869C for <dnsext@ietfa.amsl.com>; Thu, 14 Jun 2012 06:06:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.749
X-Spam-Level:
X-Spam-Status: No, score=-98.749 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, 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 d5Qj9FHxxzwJ for <dnsext@ietfa.amsl.com>; Thu, 14 Jun 2012 06:06:28 -0700 (PDT)
Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by ietfa.amsl.com (Postfix) with ESMTP id 0946121F8692 for <dnsext@ietf.org>; Thu, 14 Jun 2012 06:06:26 -0700 (PDT)
Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA299569084; Thu, 14 Jun 2012 15:04:44 +0200
Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id PAA00956; Thu, 14 Jun 2012 15:04:43 +0200 (MESZ)
From: Alfred Hönes <ah@TR-Sys.de>
Message-Id: <201206141304.PAA00956@TR-Sys.de>
To: dnsext@ietf.org
Date: Thu, 14 Jun 2012 15:04:42 +0200
X-Mailer: ELM [$Revision: 1.17.214.3 $]
Mime-Version: 1.0
Content-Type: text/plain; charset="hp-roman8"
Content-Transfer-Encoding: 7bit
Cc: 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: Thu, 14 Jun 2012 13:06:29 -0000

I have once more read the most recent version of the rfc6195bis
draft and can approve that most of my previous review comments
for RFC 6195 and this draft have been acted upon satisfactorily.
My special thanks to Donald for his patience with my persistent
urges to improve the clarity in the visual presentation of the
tables; I think the pleasant result is worth the efforts.


Michael Sheldon's remark about "ALL" vs. "ANY" has lead me to
once more check the updated registry tables, and I got stuck
at two details, which lead to new considerations:

(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).

(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).

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.

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.
                                           ^^^^^


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                     |
+------------------------+--------------------------------------------+