[dnsext] polishing of draft-ietf-dnsext-rfc3597-bis-01

Alfred Hönes <ah@TR-Sys.de> Wed, 27 January 2010 15:22 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 D29363A6A5F; Wed, 27 Jan 2010 07:22:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.396
X-Spam-Level:
X-Spam-Status: No, score=-101.396 tagged_above=-999 required=5 tests=[AWL=1.703, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, 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 d0rWPUV6bJfD; Wed, 27 Jan 2010 07:22:21 -0800 (PST)
Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id A196E3A695E; Wed, 27 Jan 2010 07:22:21 -0800 (PST)
Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from <owner-namedroppers@ops.ietf.org>) id 1Na9Za-0002WY-2Y for namedroppers-data0@psg.com; Wed, 27 Jan 2010 15:12:50 +0000
Received: from [213.178.172.147] (helo=TR-Sys.de) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from <A.Hoenes@TR-Sys.de>) id 1Na9ZN-0002U7-5m for namedroppers@ops.ietf.org; Wed, 27 Jan 2010 15:12:38 +0000
Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA271195142; Wed, 27 Jan 2010 16:12:22 +0100
Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id QAA08220; Wed, 27 Jan 2010 16:12:21 +0100 (MEZ)
From: Alfred Hönes <ah@TR-Sys.de>
Message-Id: <201001271512.QAA08220@TR-Sys.de>
Subject: [dnsext] polishing of draft-ietf-dnsext-rfc3597-bis-01
To: gson@araneus.fi, namedroppers@ops.ietf.org
Date: Wed, 27 Jan 2010 16:12:20 +0100
X-Mailer: ELM [$Revision: 1.17.214.3 $]
Mime-Version: 1.0
Content-Type: text/plain; charset="hp-roman8"
Content-Transfer-Encoding: 8bit
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
List-ID: <namedroppers.ops.ietf.org>
List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with
List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body.
List-Archive: <http://ops.ietf.org/lists/namedroppers/>

A few notes on the revised "Handling of Unknown RR Types" draft,
draft-ietf-dnsext-rfc3597-bis-01.

First of all, thanks to Andreas for acting on the previous comments.
It looks like this draft is almost ready for WGLC.


(1)  Definitions

The draft has a useful Section 2, "Definitions".
However, the definition of "well-known RR type" is buried in
Section 4.  I suggest to move that definition into Section 2
and adjust the text in Section 4 accordingly.  For instance:

Append a new paragraph to Section 2:

   A "RR of well-known type" is hereby specified as having one of the
   RR types defined in [RFC1035].  (This term has been introduced by
   [RFC3597] and is not changed herby.)

Edit the 2nd paragraph of Section 4:

   To avoid such corruption, servers MUST NOT compress domain names
   embedded in the RDATA of types that are class-specific or not well-
   known.  This requirement was stated in [RFC1123] without defining the
|  term "well-known"; it is hereby specified that only the RR types
|  defined in [RFC1035] are to be considered "well-known".
---
   To avoid such corruption, servers MUST NOT compress domain names
   embedded in the RDATA of types that are class-specific or not well-
   known.  This requirement was stated in [RFC1123] without defining the
|  term "well-known" (now introduced in Section 2 above).


(2)  Text Representation -- format rules

The list of 'word' in Section 5 might be improved visually
by making use of "symbols" type list format, e.g. using dashes
or asterisks.

Also, guided by the example at the end of the section, I suggest
to refer to the RFC 1035 rules for line folding (using parentheses).
The introductory clause only talks about white space; so some
elaborations as to what is regarded white space here seem to be
appropriate.  (Similarity to the "CFWS" construct in email!)
After re-reading the related part of RFC 1035, I therefore also
suggest adding a note that recalls the possibility of semicolon-
delimited end-of-line comments as defined in RFC 1035.

These additions hopefully make the specification here more self-
contained (last para of Section 1!) and admonish implementers to not
forget the general rules.  :-)

Cumulative proposed edits:

   The RDATA section of an RR of unknown type is represented as a
   sequence of white space separated words as follows:

      The special token \# (a backslash immediately followed by a hash
      sign), which identifies the RDATA as having the generic encoding
      defined herein rather than a traditional type-specific encoding.

      An unsigned decimal integer specifying the RDATA length in octets.

      Zero or more words of hexadecimal data encoding the actual RDATA
---
   The RDATA section of an RR of unknown type is represented as a
   sequence of white space separated words as follows:

|  *  The special token \# (a backslash immediately followed by a hash
      sign), which identifies the RDATA as having the generic encoding
      defined herein rather than a traditional type-specific encoding.

|  *  An unsigned decimal integer specifying the RDATA length in octets.

|  *  Zero or more words of hexadecimal data encoding the actual RDATA
      field, each containing an even number of hexadecimal digits.
|
|  The line-folding rules of Section 5.1 of [RFC1035] apply (they allow
|  the use of parentheses as special-purpose "white space" in order to
|  admit embedded end-of-lines in the RDATA representation).  Similarly,
|  end-of-line comments (starting with a semicolon and extending to the
|  end of a line) are allowed per Section 5.1 of [RFC1035].


(3)  Change Summary

We are going to obsolete RFC 3597 and heading for DS with this draft.
IESG rules thus require describing the differences of the memo from
its predecessor in some part of the document that is not doomed to be
stripped off by the RFC Editor.

Therefore, it might be wise to add a section (or Appendix)
"Changes Since RFC 3597" that gives a condensed summary of
the current Appendix A.

To save space and work, such section might start with:

  "Important differences from RFC 3597 have been highlighted in the
   preceding sections.  Further changes include:  ..."


(4)  Nit
                                      v
In the Abstract:  s/should not requires/should not require/


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