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
- [dnsext] rfc6195bis registration template clarifi… Alfred Hönes
- Re: [dnsext] rfc6195bis registration template cla… Donald Eastlake
- Re: [dnsext] rfc6195bis registration template cla… Olafur Gudmundsson
- Re: [dnsext] rfc6195bis registration template cla… Donald Eastlake
- Re: [dnsext] I-D Action: draft-ietf-dnsext-rfc619… Alfred Hönes
- Re: [dnsext] I-D Action: draft-ietf-dnsext-rfc619… Donald Eastlake