Re: [dnsext] WGLC: RFC5395bis obsoleting RFC5395
Alfred Hönes <ah@TR-Sys.de> Fri, 19 November 2010 20:10 UTC
Return-Path: <dnsext-bounces@ietf.org>
X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org
Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8151C28C105; Fri, 19 Nov 2010 12:10:12 -0800 (PST)
X-Original-To: dnsext@core3.amsl.com
Delivered-To: dnsext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51CC528C105 for <dnsext@core3.amsl.com>; Fri, 19 Nov 2010 12:10:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.367
X-Spam-Level:
X-Spam-Status: No, score=-98.367 tagged_above=-999 required=5 tests=[AWL=0.382, 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pJytSzfPTdO3 for <dnsext@core3.amsl.com>; Fri, 19 Nov 2010 12:10:09 -0800 (PST)
Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id B5AFA3A689C for <dnsext@ietf.org>; Fri, 19 Nov 2010 12:10:06 -0800 (PST)
Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA254207435; Fri, 19 Nov 2010 21:10:35 +0100
Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id VAA18117; Fri, 19 Nov 2010 21:10:34 +0100 (MEZ)
From: Alfred Hönes <ah@TR-Sys.de>
Message-Id: <201011192010.VAA18117@TR-Sys.de>
To: dnsext@ietf.org, d3e3e3@gmail.com
Date: Fri, 19 Nov 2010 21:10:33 +0100
X-Mailer: ELM [$Revision: 1.17.214.3 $]
Mime-Version: 1.0
Subject: Re: [dnsext] WGLC: RFC5395bis obsoleting RFC5395
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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
> Remember this last call ends over the weekend. > > Olafur Olafur, thanks for the heads-up! In general: Support. Minor concerns: (1) Section 5 and Annex A call for use of the dns-rrtype-applications AT ietf.org mailing list, but the two descriptions of the purpose and usage do not match precisely. I'd appreciate a consistent clarification of who's to send to that address at which stage of the process. IIUC what Section 5 says, only the expert(s) should be able to send to dns-rrtype-applications, and this is the final step in the review, which triggers IANA's clerical workflow; this should be made more explicit. (See below.) Wouldn't dns-rrtype-applications AT IANA.ORG make more sense for the purpose indicated in Annex A? Sections 1, 3.1.1, and 3.1.2 and Annex B point to dnsext AT ietf.org for discussion. To avoid surprise/confusion, it might be wise to mention the dns-rrtype-applications email address and its use by the expert(s) in an additional paragraph appended to 3.1.2. (2) I suggest to turn text in Sect. 5 to past tense where it actually describes what IANA already has done on behalf of RFC 5395, to better distinguish that from the References and mailing list name update that IANA will have to perform for this memo; e.g. s/IANA shall establish/IANA has established/ Nits: a) The draft uses old (verbous++) "Status of This Memo" boilerplate. b) Essential procedural clauses are hidden therein: It is intended to become the new BCP 42 obsoleting RFC 5395. Comments should be sent to the DNS Extensions Working Group mailing list <dnsext@ietf.org>. Nobody reads the (assumed) boilerplate text. Therefore, it might be preferable to place these sentences in an additional front note (using the xml2rfc <note> element inside <front>). c) It looks like the draft was based on a draft for RFC 5395 and RFC-Ed changes retrofitted; yet, I miss some of the editorial improvements applied in the RFC. (For instance, compare the unpleasant layout of the table in section 2.2 with the much better readable version in RFC 5395.) This can be fixed at the RFC Editor. Note that a rfcdiff of the RFC and the current draft might be more instructive than the standard diffs offered at tools.ietf.org ; use: <http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url1=rfc5395.txt &url2=draft-ietf-dnsext-5395bis-01.txt> But also note that this diff tool hides formating changes, e.g. in table alignment or References. d) In the table in 3.1.4, hyphen is used for interval ranges *and* to separate values from description. In combination with the irregular indentation, that's rather confusing: -------- snip -------- 0 0x0000 - Reserved; allocation requires IETF Standards Action. 1 0x0001 - Andrews File Service v3.0 Location Service [RFC1183]. 2 0x0002 - DCE/NCA root cell directory node [RFC1183]. 3 - 65,279 0x0003 - 0xFEFF - Allocation by IETF Review. 65,280 - 65,534 0xFF00 - 0xFFFE - Private Use. 65,535 0xFFFF - Reserved; allocation requires IETF Standards Action. -------- snip -------- A better layout with columnar alignment would look like this: -------- snip -------- 0 0x0000 Reserved; allocation requires IETF Standards Action 1 0x0001 Andrews File Service v3.0 Location Service [RFC1183] 2 0x0002 DCE/NCA root cell directory node [RFC1183] 3 - 65,279 0x0003 - 0xFEFF Allocation by IETF Review 65,280 - 65,534 0xFF00 - 0xFFFE Private Use 65,535 0xFFFF Reserved; allocation requires IETF Standards Action -------- snip -------- (Note: Trailing periods are not needed in the table; dropping these allows to adhere to the margins.) e) Similar considerations apply to the table in 3.2. f) Other SDOs use "Annex" for normative appendices, yes, but the RFC Editor doesn't like that. :-( "Annex B" however is likely to be regarded as non-normative; so "Annex" isn't a good match. g) FYI: Idnits yields funny comments. :-) (No action needed.) 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
- Re: [dnsext] WGLC: RFC5395bis obsoleting RFC5395 Olafur Gudmundsson
- [dnsext] WGLC: RFC5395bis obsoleting RFC5395 Olafur Gudmundsson
- Re: [dnsext] WGLC: RFC5395bis obsoleting RFC5395 Alfred Hönes
- Re: [dnsext] WGLC: RFC5395bis obsoleting RFC5395 Andrew Sullivan
- [dnsext] WGLC Summary Re: WGLC: RFC5395bis obsole… Olafur Gudmundsson