Subject: RFC 4592 errata

From: Alfred Hönes <[email-masked]>
Date: Sat, 12 Aug 2006 17:33:21 +0200 (MESZ)

Hello,
reading the recently published RFC 4592 (DNSEXT WCARD)
authored by you, I found a few textual issues that should
be noted.  (Apparently, most of these issues have been
introduced after the I-D version I had read last year.)

I use change bars ('|' in column 1) to mark issues/changes.
Proposed (changed) text is re-adjusted to conform with RFC
formatting rules.

(1)  [improper/misleading wording]

In the explanations to the Example in Section 2.2.1, RFC 4592
(near the top of page 9) says:

|  The following responses would not be synthesized from any of the
|  wildcards in the zone:

This wording is improper/misleading.
Perhaps, the RFC should better say:

|  The following queries would not cause RRs to be synthesized for the
|  answer from any of the wildcards in the zone:

(2)  [typo]

The last paragraph of Section 2.2.2, on page 10, says:

   As RFC 1034 also defines "an authoritative name error indicating that
|  the name does not exist" in section 4.3.1, so this apparently is not
   the intent of the original definition, justifying the need for an
   updated definition in the next section.

"As ..., so ..." is redundant.
Thus, the RFC should say instead:

   As RFC 1034 also defines "an authoritative name error indicating that
|  the name does not exist" in section 4.3.1, this apparently is not the
   intent of the original definition, justifying the need for an updated
   definition in the next section.

(3)  [typo]

In Section 3.3.1, the 4th paragraph, on page 12, says:

   A source of synthesis does not guarantee having a RRSet to use for
   synthesis.  The source of synthesis could be an empty non-terminal.

It should say:

|  A source of synthesis does not guarantee having an RRSet to use for
   synthesis.  The source of synthesis could be an empty non-terminal.

(4)  [typo]

In Section 3.3.3, the last paragraph on page 13 says:

   This is essentially the same text in part 'a' covering the processing
   of CNAME RRSets.

It should say:

|  This is essentially the same text as in part 'a' covering the
   processing of CNAME RRSets.

(5)  [incomplete change in example?]

In Section 4.4, the second-to-last paragraph on page 16 says:

   The DNAME specification is not clear on whether DNAME records in a
   cache are used to rewrite queries.  In some interpretations, the
   rewrite occurs; in others, it does not.  Allowing for the occurrence
   of rewriting, queries for "sub.a.b.example. A" may be rewritten as
|  "sub.foo.bar.tld. A" by the former caching server and may be
|  rewritten as "sub.a.foo.bar.tld. A" by the latter.  Coherency is
   lost, and an operational nightmare ensues.

"tld." does never appear in the preceding text; apparently it has
been replaced there by "example.net."
Therefore, the RFC should say instead:

   The DNAME specification is not clear on whether DNAME records in a
   cache are used to rewrite queries.  In some interpretations, the
   rewrite occurs; in others, it does not.  Allowing for the occurrence
   of rewriting, queries for "sub.a.b.example. A" may be rewritten as
|  "sub.foo.bar.example.net. A" by the former caching server and may be
|  rewritten as "sub.a.foo.bar.example.net. A" by the latter.  Coherency
   is lost, and an operational nightmare ensues.

I propose to publish an RFC Errata Note to address these issues,
making use of the material above.

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