Re: [dnsext] I-D Action: draft-ietf-dnsext-rfc6195bis-01

Alfred Hönes <ah@TR-Sys.de> Fri, 04 May 2012 16:01 UTC

Return-Path: <dnsext-bounces@ietf.org>
X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org
Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C45A21F846F; Fri, 4 May 2012 09:01:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1336147279; bh=utaIRy+fu70G0GySHtjks38/JXN+mnbPjod8xVWCMN8=; h=From:Message-Id:To:Date:In-Reply-To:Mime-Version:Cc:Subject: List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=AGKVhFqEXaPxZhazht34adDn+4ZGOCCiAjoYXwlz862I6/EU/aCw3n2Req3SeF2Os z2aUrNEAku3iiCWZJeLgyJNMtZJ9xxC2q5URZ7WcXUJ8mYW5O2Y163Yj8R+MfITZbY mOjpexYD3bQHkgrsYaqh29Jyj7u1rKEHGxBlTLeo=
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 9541021F846F for <dnsext@ietfa.amsl.com>; Fri, 4 May 2012 09:01:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.239
X-Spam-Level:
X-Spam-Status: No, score=-98.239 tagged_above=-999 required=5 tests=[AWL=0.510, 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 ITM65fKhfvLV for <dnsext@ietfa.amsl.com>; Fri, 4 May 2012 09:01:16 -0700 (PDT)
Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by ietfa.amsl.com (Postfix) with ESMTP id 9914621F8452 for <dnsext@ietf.org>; Fri, 4 May 2012 09:01:15 -0700 (PDT)
Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA189557187; Fri, 4 May 2012 17:59:47 +0200
Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id RAA07247; Fri, 4 May 2012 17:59:46 +0200 (MESZ)
From: Alfred Hönes <ah@TR-Sys.de>
Message-Id: <201205041559.RAA07247@TR-Sys.de>
To: d3e3e3@gmail.com
Date: Fri, 04 May 2012 17:59:45 +0200
In-Reply-To: <CAF4+nEGMbVpagbo-q1ic5Ejkaf5NsqpJ_4tmLog8F05HqT_YOQ@mail.gmail.com> from Donald Eastlake at May "3, " 2012 "02:42:26" pm
X-Mailer: ELM [$Revision: 1.17.214.3 $]
Mime-Version: 1.0
Cc: dnsext@ietf.org
Subject: Re: [dnsext] I-D Action: draft-ietf-dnsext-rfc6195bis-01
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: dnsext-bounces@ietf.org
Errors-To: dnsext-bounces@ietf.org

Donald,

I really do appreciate all the efforts you have undertaken on the
rfc6195bis draft, in particular the pain to improve the clarity and
readability of the tables, which now all look pretty nice and clear.

I have once more taken a full proofreading pass over the draft and
think we're almost done with it now, so the Chairs might as well
announce WGLC now.
In that case, the few remarks below should be regarded as early WGLC
comments.


(1)  Small gap in assignment rules

Now recently also dealing with the newest rfc3597bis draft,
I found a single new topic that preferably should be clarified
in the rfc6195bis document before publication:

RFC 3597 (and again, rfc3597bis) define the 'synthetic' names
to be used in the presentation format as the mnemonics for
unknown CLASSes and RRTYPEs.
For completeness and to protect against accidents, I suggest that
very tiny clauses be added to the draft to indicate that these
names must not be assigned by IANA:

(1.1)

The 4th paragraph of Section 3.1 says:

|  RRTYPEs have mnemonics that must be completely disjoint from the
|  mnemonics used for CLASSes and that must match the following regular
|  expression:
|
|        [A-Z][A-Z0-9\-]*[A-Z0-9]

I propose to insert after this snippet the new clause:

|  Additionally, the 'synthetic' CLASS and RRTYPE names specified in
|  Section 5 of [RFC3597] cannot be assigned as new RRTYPE mnemonics.

Note that the 'synthetic' names also conform to the RE shown, so the
present text does not preclude abuse.

Using this (arguably unpleasant) indirect specification, room is
left for potential future directions of rfc3597bis/ter/...  :-)

RFC 3597 already is listed as a Normative Reference, so no change
in References is needed.

(1.2)

Similarly, the 4th paragraph of Section 3.2 says:

|  CLASSes have mnemonics that must be completely disjoint from the
|  mnemonics used for RRTYPEs and that must match the following regular
|  expression:
|
|        [A-Z][A-Z0-9\-]*[A-Z0-9]

... and I propose to insert after this snippet the new clause:

|  Additionally, the 'synthetic' CLASS and RRTYPE names specified in
|  Section 5 of [RFC3597] cannot be assigned as new CLASS mnemonics.


(2)  Section 3.1.1 -- visual grouping of rules

As mentioned recently on the list, it turned out to be a little hard
to locate the processing rules for new RRTYPEs that cannot be treated
by the customized Expert Review process described in the draft.

I think this could be made better without changing the text, by
simply re-grouping the first 2 paragraphs of Section 3.1.1; the first
sentence of the current 2nd para logically belongs to the context
of the 1st para, as it deals with the Expert Review only, and the
2nd sentence in the 2nd para describes the procedure to be followed
when the subsequently listed preconditions for the Expert Review
process are not met.  So I suggest to pack the 1st sentence to the
1st para and leave the conditional rules alone in the 2nd para.

OLD:

|  Parameter values specified in Section 3.1 above, as assigned based on
   DNS RRTYPE Allocation Policy, are allocated by Expert Review if they
   meet the two requirements listed below. There will be a pool of a
   small number of Experts appointed by the IESG. Each application will
   be judged by an Expert selected by IANA. In any case where the
   selected Expert is unavailable or states they have a conflict of
|  interest, IANA may select another Expert from the pool.
|
|  Some guidelines for the Experts are given in Section 3.1.2. RRTYPEs
   that do not meet the requirements below may nonetheless be allocated
   by a Standards Action as modified by [RFC4020].

NEW:

|  Parameter values specified in Section 3.1 above as assigned based on
   DNS RRTYPE Allocation Policy, are allocated by Expert Review if they
   meet the two requirements listed below. There will be a pool of a
   small number of Experts appointed by the IESG. Each application will
   be judged by an Expert selected by IANA. In any case where the
   selected Expert is unavailable or states they have a conflict of
|  interest, IANA may select another Expert from the pool.  Some
|  guidelines for the Experts are given in Section 3.1.2.
|
|  RRTYPEs that do not meet the requirements below may nonetheless be
|  allocated by a Standards Action as modified by [RFC4020].

Note that the present comma in the first line seems to be spurious,
unnaturally separating   "... specified ... above as assigned ..."


(3)  Remaining nits

(3.1)  Section 3.1, table heading

The heading for the 2nd table column is slightly misaligned;
   s/Assignment Policy/  Assignment Policy/

(3.2)  Section 3.1.4, leading paragraph

Please fix the typo:  s/as show below/as shown below/

(3.3)  Section 3.2, precision in text for 2 table entries

In the table in Section 3.2, some descriptions have been clarified/
improved by replacing "assigned" by "available for assignment",
but two entries have been missed.  I suggest that this be aligned
using the improved wording already introduced in other entries.
Below, I have shortened the present text at the end to avoid
overflow into an additional line.)

OLD:

   32,768 - 57,343
|  0x8000 - 0xDFFF   Assigned for data CLASSes only; Specification
|                    Required for new assignments

   57,344 - 65,279
|  0xE000 - 0xFEFF   Assigned for QCLASSes and meta-CLASSes only;
|                    Specification Required for new assignments

NEW:

   32,768 - 57,343
|  0x8000 - 0xDFFF   Available for assignment to data CLASSes only;
|                    Specification Required

   57,344 - 65,279
|  0xE000 - 0xFEFF   Available for assignment to QCLASSes and meta-
|                    CLASSes only; Specification Required


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 mailing list
dnsext@ietf.org
https://www.ietf.org/mailman/listinfo/dnsext