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