Subject: draft-ietf-dnsext-rfc2672bis-dname-13 -- another iteration

From: Alfred Hönes <[email-masked]>
Date: Sat, 3 May 2008 16:25:20 +0200 (MESZ)

[ Moderators note: Post was moderated, either because it was posted by
   a non-subscriber, or because it was over 20K.  
   With the massive amount of spam, it is easy to miss and therefore 
   delete relevant posts by non-subscribers. 
   Please fix your subscription addresses. ]

Hello all,

Once again closely reading the rfc2672bis-dname-13 I-D,
I found another few details that should be considered.

[ Apparently, the human brain needs intermediate versions
  to uncover subtle inconsistencies previously 'hidden'
  underneath more substantial issues.  :-)  ]

(1)  Front matter

The discussion so far has centered around the logical role
of the new document, and it is now accepted consensus that
it is intended as a full replacement of RFC 2672, which it
will obsolete therefore.

This leaves the document Title and the Abstract alone,
both still talking of 'update'.  For logical consistency,
and to avoid misinterpretations, I therefore suggest the
following changes, also recognizing that the introduction of
the UD bit is an additional performance optimization newly
introduced in this *revision* of the DNAME specification.

a) document title:

      Update to DNAME Redirection in the DNS
---
      DNAME Redirection in the DNS (Revised)

   (Note:  I do not insist on this particular wording;
    please substitute a better proposal if you have one.)

b) in the Abstract:

                                                         [...].  This is
   an update of the original specification in RFC 2672, also aligning
   RFC 3363 and RFC 4294 with this revision.
---
                                                         [...].  This is
   a revision of the original specification in RFC 2672, also aligning
   RFC 3363 and RFC 4294 with this revision.

A few similar changes are embedded below, all in the intent to
consistently replace "update to 2672" by "revision of 2672",
but for the sake of brevity, I do not present an exhaustive list.
The goal is leaving "update" only in the context of "Dynamic DNS
Update" [RFC2136], EDNS(0) [RFC2671] Flags update for the UD bit,
and IANA actions).

(2)  Examples in Section 1

Once more reconsidering the nature of the examples presented
in paragraphs 4 and 5 of Section 1, I now observed that the
two major kinds of application ought to be better characterized
(keep in mind, "redirection" is always performed), and that the
ENUM example better fits with the reverse mapping scenario than
the "domain aliasing" scenario (punnycode alternatives), in which
the driving force is to make a single domain name tree available
below *multiple* higher level domain names.

Currently, the -dname-13 draft says:

   This document is an update of the original specification of DNAME in
   RFC 2672 [RFC2672].  DNAME was conceived to help with the problem of
   maintaining address-to-name mappings in a context of network
   renumbering.  With a careful set-up, a renumbering event in the
   network causes no change to the authoritative server that has the
   address-to-name mappings.  Examples in practice are classless reverse
   address space delegations.

   Another usage of DNAME lies in redirection of name spaces.  For
   example, a zone administrator may want sub-trees of the DNS to
   contain the same information.  Examples include punycode alternates
   for domain spaces.  DNAME is also used for the redirection of ENUM
   domains to another maintaining party.

I suggest the following modifications:

                    vvvvvvvvvv
|  This document is a revision of the original specification of DNAME in
   RFC 2672 [RFC2672].  DNAME was conceived to help with the problem of
   maintaining address-to-name mappings in a context of network
   renumbering.  With a careful set-up, a renumbering event in the
   network causes no change to the authoritative server that has the
|  address-to-name mappings.  The primary examples in practice are
|  classless reverse address space delegations.  Similarly, DNAME is
|  also used for the redirection of ENUM domains to another maintaining
|  party.
                                  vvvvvvvv    vvvv
|  Another usage of DNAME lies in aliasing of DNS name spaces.  For
   example, a zone administrator may want sub-trees of the DNS to
   contain the same information.  Examples include punycode alternates
|  for domain spaces.
                      ^^^...

(3)  Section 2.5 --
     better clarification of history, and role of document

The second paragraph of Section 2.5 says:

   Although the previous DNAME specification [RFC2672] (that is
   obsoleted by this specification) talked about signaling to allow
   compression of the target name, such signaling is not specified.

To better bridge the historical and semantical gaps, I suggest to
add a few clarifying words:

   Although the previous DNAME specification [RFC2672] (that is
   obsoleted by this specification) talked about signaling to allow
|  compression of the target name, such signaling has never been
|  specified and purposely also is not specified here.

The third paragraph says:

   RFC 2672 stated that the EDNS version had a meaning for understanding
|  of DNAME and DNAME target name compression.  This document updates
   RFC 2672, in that there is no EDNS version signaling for DNAME.
   [...]

In line with the rationale presented for item (1) above, I suggest to
there also replace "updates" by "revises":

   RFC 2672 stated that the EDNS version had a meaning for understanding
|  of DNAME and DNAME target name compression.  This document revises
   RFC 2672, in that there is no EDNS version signaling for DNAME.
   [...]

(4)  Section 3.2 -- nit

In the first section, for consistency with other parts of the text,
"(Understand-DNAME)" should be spelled with the joining hyphen.
[Missed from last review]

(5)  Section 5.3.2

The leading text line is rather terse.  I suggest to turn it into
a full sentence, e.g.:

   Examples of why DNSSEC validators MUST understand DNAME.
---
   Below are examples of why DNSSEC validators MUST understand DNAME.
   ^^^^^^^^^^^

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:  [email-masked]                     |
+------------------------+--------------------------------------------+

Spam detection software, running on the system "mail.ogud.com", has
identified this incoming email as possible spam.  The original message
has been attached to this so you can view it (if it isn't spam) or label
similar future email.  If you have any questions, see
The administrator of that system for details.

Content preview:  [ Moderators note: Post was moderated, either because it was
   posted by a non-subscriber, or because it was over 20K. With the massive
  amount of spam, it is easy to miss and therefore delete relevant posts by
  non-subscribers. Please fix your subscription addresses. ] [...] 

Content analysis details:   (3.0 points, 4.0 required)

 pts rule name              description
---- ---------------------- --------------------------------------------------
 3.4 HEADER_SPAM            Bulk email fingerprint (header-based) found
 3.2 CHARSET_FARAWAY_HEADER A foreign language charset used in headers
-2.3 BAYES_00               BODY: Bayesian spam probability is 0 to 1%
                            [score: 0.0000]
 0.1 RDNS_NONE              Delivered to trusted network by a host with no rDNS
-1.4 AWL                    AWL: From: address is in the auto white-list