draft-ietf-dnsext-2929bis-07

Alfred Hönes <ah@tr-sys.de> Thu, 04 September 2008 15:25 UTC

Return-Path: <owner-namedroppers@ops.ietf.org>
X-Original-To: ietfarch-dnsext-archive@core3.amsl.com
Delivered-To: ietfarch-dnsext-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 601B93A697B; Thu, 4 Sep 2008 08:25:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.668
X-Spam-Level: **
X-Spam-Status: No, score=2.668 tagged_above=-999 required=5 tests=[AWL=-0.336, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id klKT3hzKbarU; Thu, 4 Sep 2008 08:25:09 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id ECD1B3A685A; Thu, 4 Sep 2008 08:25:08 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from <owner-namedroppers@ops.ietf.org>) id 1KbGXi-0008lS-3H for namedroppers-data@psg.com; Thu, 04 Sep 2008 15:14:42 +0000
Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from <namedroppers@stora.ogud.com>) id 1KbGXc-0008kr-Q2 for namedroppers@ops.ietf.org; Thu, 04 Sep 2008 15:14:40 +0000
Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.2/8.14.2) with ESMTP id m84FEYug061421 for <namedroppers@ops.ietf.org>; Thu, 4 Sep 2008 11:14:35 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com)
Received: (from namedroppers@localhost) by stora.ogud.com (8.14.2/8.14.2/Submit) id m84FEYtX061420 for namedroppers@ops.ietf.org; Thu, 4 Sep 2008 11:14:34 -0400 (EDT) (envelope-from namedroppers)
Received: from [213.178.172.147] (helo=WOTAN.TR-Sys.de) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from <A.Hoenes@tr-sys.de>) id 1KbCuE-000BR4-Up for namedroppers@ops.ietf.org; Thu, 04 Sep 2008 11:21:46 +0000
Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA011037230; Thu, 4 Sep 2008 13:20:30 +0200
Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id NAA12792; Thu, 4 Sep 2008 13:20:24 +0200 (MESZ)
From: Alfred Hönes <ah@tr-sys.de>
Message-Id: <200809041120.NAA12792@TR-Sys.de>
Subject: draft-ietf-dnsext-2929bis-07
To: d3e3e3@gmail.com, townsley@cisco.com
Date: Thu, 04 Sep 2008 13:20:23 +0200
Cc: iesg@ietf.org, namedroppers@ops.ietf.org
X-Mailer: ELM [$Revision: 1.17.214.3 $]
Mime-Version: 1.0
Content-Type: text/plain; charset="hp-roman8"
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
List-ID: <namedroppers.ops.ietf.org>

[ Moderators note: Post was moderated, either because it was posted by
   a non-subscriber, or because it was over 20K.  
   With the massive amount of spam, it is easy to miss and therefore 
   delete relevant posts by non-subscribers. 
   Please fix your subscription addresses. ]

Hello all,
eventually I found the time to also (and once more) closely study
the latest version of the DNS IANA Considerations draft,
     draft-ietf-dnsext-2929bis-07.

I apologize for being very late, but ...

Beyond a few nits [[ see section (B) below ]] that should be
addressed before publication as an RFC, I arrived at considerations
[[ see (A) below ]] that might motivate a small change in the RCODE
assignments.


(A)  Section 2.3 -- RCODE

The current draft "reserves" RCODE 65,535 (0xFFFF) for future
IETF Standards Action -- see below.

Also, in the first paragraph of Section 2.3, the draft says:

   It would appear from the DNS header above that only four bits of
   RCODE, or response/error code are available. However, RCODEs can
   appear not only at the top level of a DNS response but also inside
|  OPT RRs [RFC2671], TSIG RRs [RFC2845], and TKEY RRs [RFC2930]. The
|  OPT RR provides an eight-bit extension resulting in a 12-bit RCODE
|  field and the TSIG and TKEY RRs have a 16-bit RCODE field.

This means that the extensibility envisioned by reserving
RCODE 0xFFFF will not work for the restricted 12-bit RCODE
sub-namespace in the OPT RR.

Perhaps, it would be a good idea to also reserve one RCODE code
point in this 12-bit sub-namespace for future extensibility within
the framework of the EDNS0 OPT RR.

The draft tabulates in Section 2.3 :

        RCODE   Name    Description                        Reference
        Decimal
          Hexadecimal

        ...

|       23 - 3,840
|         0x0017 - 0x0F00   Available for assignment

        3,841 - 4,095
          0x0F01 - 0x0FFF   Private Use

        4,096 - 65,534
          0x1000 - 0xFFFE   Available for assignment

!       65,535
!         0xFFFF            Reserved, can only be allocated by an IETF
!                           Standards Action.


The code point 0x0FFF would be the natural analogon in the 12-bit
sub-namespace to the role of 0xFFFF in the 16-bit namespace.
But since the above assignment of 0x0FFF for Private Use is
inherited from RFC 2929 and should not be changed without very
significant reasons, the natural choice will perhaps be 0x0F00.

Therefore, to keep a reserved path for extensibility within the
12-bit RCODE sub-namespace for the OPT RR, I suggest to reserve
0x0F00 for future IETF Standards Action.

To this end, the above snippit of the table in Section 2.3 of the
draft needs to be changed to:

        ...

|       23 - 3,839
                ^^    vvv
|         0x0017 - 0x0EFF   Available for assignment
|
|       3,840
|         0x0F00            Reserved, can only be allocated by an IETF
|                           Standards Action.

        3,841 - 4,095
          0x0F01 - 0x0FFF   Private Use

        ...


(B)  Further nits

(1)  Section 2, 1st paragraph below the diagram:

The draft says:

   The ID field identifies the query and is echoed in the response so
|  they can be matched.
   ^^^^
I suggest to   s/they/it/  :

   The ID field identifies the query and is echoed in the response so
|  it can be matched.
   ^^

(2)  Section 2.2

The columnar alignment within the table in 2.2 should be improved,
to make it more pleasant and readable, by shifting most of the
References to the right by 8 character positions :

|         OpCode Name                      Reference

|          0     Query                     [RFC1035]
           1     IQuery  (Inverse Query, Obsolete) [RFC3425]
|          2     Status                    [RFC1035]
           3     available for assignment
|          4     Notify                    [RFC1996]
|          5     Update                    [RFC2136]
          6-15   available for assignment

---                                        ^^^^^^^^

|         OpCode Name                              Reference

|          0     Query                             [RFC1035]
           1     IQuery  (Inverse Query, Obsolete) [RFC3425]
|          2     Status                            [RFC1035]
           3     available for assignment
|          4     Notify                            [RFC1996]
|          5     Update                            [RFC2136]
          6-15   available for assignment


Kind regards,
  Alfred Hönes.

-- 

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


--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>