Subject: [dnsext] draft-ietf-dnsext-axfr-clarify-11

From: Alfred Hönes <[email-masked]>
Date: Wed, 1 Apr 2009 16:11:39 +0200 (MESZ)

Edward,
thanks for your work on updating the AXFR draft.
I have followed up to the new version,
      draft-ietf-dnsext-axfr-clarify-11,
and did not find any more substantial flaws.

Therefore, I strongly suggest that the chairs now call out
this draft for WGLC.

In this case, please regard this message as a WGLC comment.

Below, I have assembled a list of editorials left over from
previous draft versions or newly introduced with new text
into the -11 version.
I suggest that these details be addressed together with any
potential WGLC comments in a final draft version before
handing the document over to the IESG.

(1)  Abstract -- spurious comma

  The definition of AXFR, has proven insufficient ...
---                     ^
  The definition of AXFR has proven insufficient ...

(2)  Section 2, last para -- language 'OBE'

The draft says:
                                   vvvvvv
| Field names used in this document will correspond to the names as they
  appear in the IANA registry for DNS Header Flags [DNSFLGS].

That was literally perfect until a new paragraph has been inserted
before, giving a preview of the treatment of the TC bit.  This way,
the "will" has become moot; I suggest to simply drop this word:

                                   v
| Field names used in this document correspond to the names as they
  appear in the IANA registry for DNS Header Flags [DNSFLGS].

(3)  Section 2.1, 1st para -- copyedit flaw

The first paragraph is the old text that was intended to be
replaced by the new text that now appears as the second paragraph
in the section, but inadvertantly has been kept.

So please delete the first paragraph in 2.1.

(4)  Section 2.2, 3rd para -- clarification

I still fear that the current text might be considered misleading.
The draft says:
                                                                vvvvvvv
| An AXFR response that is indicating an error MUST consist of a single
  DNS message with the return code set to the appropriate value for the
  condition encountered - once the error condition is detected. Such
  a message MUST terminate the AXFR session; it MUST copy the Query
  Section from the AXFR query into its Query Section, but the inclusion
  of the terminating SOA resource record is not necessary.

  An AXFR client might receive a number of AXFR response messages
  free of an error condition before the message indicating an error
  is received.

The last paragraph also quoted above clarifies that an error response
can consist of multiple DNS messages, formally contradicting the
"single" in the first line of the third paragraph.
Thus, the phrase,
   "An AXFR response ... indicating an error MUST consist
    of a single DNS message ..."
is misleading and should be reworded for clarity.
Actually, the error response may consist of multiple AXFR response
messages, with exactly one (the last one) carrying an error code.
This should be unambiguously clear from the first mention.

Here is a new proposal using simplified language for the first
sentence in the third paragraph:

| An AXFR response indicates an error via a single DNS message with the
  return code set to the appropriate value for the condition encountered
| - sent once the error condition is detected.  Such
  a message MUST terminate the AXFR session; it MUST copy the Query
  Section from the AXFR query into its Query Section, but the inclusion
  of the terminating SOA resource record is not necessary.

(5)  Section 3.1, last paragraph -- improper plural

Please correct:
                                                           vv
| Zones for which it is impractical to list the entire zones for a serial
  number ...
---                                                        v
| Zones for which it is impractical to list the entire zone for a serial
  number ...

(6)  Section 3.2, bullets below "Informally:"

There are two typos in these bullets.
[ Sorry, I'm eventually guilty myself for these.  :-( ]

-  3rd bullet:    s/bth/both/
-  4th bullet:    s/siede/side/

(7)  Section 3.4, last para -- 'rational quotation' (#1)

Please adjust the quotation style to what has been adopted in the IETF.
There are a few instances that still need to be fixed.

The first one is at the end of the last paragraph of Section 3.4:

  Compression."
---          vv
  Compression".

(8)  Section 3.5, 1st para -- 'rational quotation' (#2)

As in (7) above, please correct at the end of the first paragraph:

  said to be "occluded."
---                   vv
  said to be "occluded".

(9)  Section 4, 3rd para -- punctuation

The comma in that paragraph separates two full sentences.
Therefore it should better be replaced by a semicolon
(or use a full stop instead, if you prefer!):

  The assumption that a TCP connection is dedicated to the single AXFR
| session is incorrect, this has led to implementation choices that
  prevent either multiple concurrent zone transfers or the use of the
  open connection for other queries.
---
  The assumption that a TCP connection is dedicated to the single AXFR
| session is incorrect; this has led to implementation choices that
  prevent either multiple concurrent zone transfers or the use of the
  open connection for other queries.

(10)  Section 4.1, last para, last sentence -- improved language

The latest changes lead to poor grammar.
[ Perhaps I'm guilty for that oversight as well.  :-( ]
I suggest to improve the sentence and punctuation as follows:

     [...]  In the reverse situation, older AXFR client and newer AXFR
  server ought to induce the server to operate within the specification
  for an older server.
---
|    [...]  The reverse situation, older AXFR client and newer AXFR
        v  ^^
| server, ought to induce the server to operate within the specification
  for an older server.

Or use:

     [...]  In the reverse situation, older AXFR client and newer AXFR
| server, the server ought to operate within the specification for an
        ^^          ^^^^^^^
  older server.

(11)  Section 4.1.1, 1st para --  'rational quotation' (#3)

Similar as above, please correct:

  is "apparent need."
---                vv
  is "apparent need".

(12)  Section 4.1.1, 3rd paragraph -- improved wording

The text near the end of the paragraph refers to previous phrases
by three keywords, where the keyword "failure" does not appear in
the text currently.  But there is un unpleasant word repetition of
"disruption", and so I suggest to   s/disruption/failure/  :

OLD:

  When a TCP connection is closed remotely (relative to the client),
  whether by the AXFR server or due to a network event, the AXFR client
  MUST cancel all outstanding sessions and non-AXFR transactions.
  Recovery from this situation is not straightforward.  If the disruption
  was a spurious event, attempting to restart the connection would be
  proper.  If the disruption was caused by a medium or long term
| disruption, the AXFR client would be wise to not spend too many
  ^^^^^^^^^^
  resources trying to rebuild the connection.  Finally, if the connection
  was dropped because of a policy at the AXFR server (as can be the case
  with older AXFR servers), the AXFR client would be wise to not retry
  the connection.  Unfortunately, knowing which of the three cases above
! (momentary disruption, failure, policy) applies is not possible with
                         !!!!!!!
  certainty, and can only be assessed by heuristics.

NEW:

  When a TCP connection is closed remotely (relative to the client),
  whether by the AXFR server or due to a network event, the AXFR client
  MUST cancel all outstanding sessions and non-AXFR transactions.
  Recovery from this situation is not straightforward.  If the disruption
  was a spurious event, attempting to restart the connection would be
  proper.  If the disruption was caused by a medium or long term
| failure, the AXFR client would be wise to not spend too many
  ^^^^^^^
  resources trying to rebuild the connection.  Finally, if the connection
  was dropped because of a policy at the AXFR server (as can be the case
  with older AXFR servers), the AXFR client would be wise to not retry
  the connection.  Unfortunately, knowing which of the three cases above
  (momentary disruption, failure, policy) applies is not possible with
  certainty, and can only be assessed by heuristics.

(13)  Section 5, last para -- 'rational quotation' (#4)

Again, please adjust:

      [...] to be "open to all."  [...]
---                           vv
      [...] to be "open to all".  [...]

(14)  Section 7.1, last para

Apparently, the last two words and the trailing period have been lost.
Please restore:

  An implementation of an AXFR server MAY permit configuring, on a per
  AXFR client basis, a need to revert to single resource record per
  message; in that case, the default SHOULD be to use multiple records
---
  An implementation of an AXFR server MAY permit configuring, on a per
  AXFR client basis, a need to revert to single resource record per
  message; in that case, the default SHOULD be to use multiple records
| per message.

(15)  Section 11, 1st para -- punctuation

I suggest to replace the trailing period by a colon (':')
to better introduce the subsequent literal quotation.

  Earlier editions of this document have been edited by Andreas
| Gustafsson. In his latest version, this acknowledgement appeared.
---
  Earlier editions of this document have been edited by Andreas
| Gustafsson. In his latest version, this acknowledgement appeared:
                                                                  ^

(16)  Section 12

a)
According to the exegesis by the IESG, RFC 2119 (BCP 14) is to
be understood as a normative reference.  So please promote the
entry '[BCP14]' in Section 12.2 to Normative, by moving it into
Section 12.1.
Further, it might be wise (and more consistent in style)
to also use '[RFC2119]' in place of '[BCP14]'.

b)
As a service to the reader, I suggest to restore the collation order
(i.e. RFCs listed in ascending RFC number order) in Section 12.1.
The order has been distorted a bit by updates due to obsolescences
and late additions.
The following entries need to be moved down to the proper plase:
  [RFC5395] , [RFC4509] , and [RFC5155] .

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

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Edward Lewis <[email-masked]>
Date: Wed, 1 Apr 2009 14:16:11 -0400

I processed these suggestions - and am waiting on hearing from the WG's chairs.

>(1) (2) (3)

ack cubed

>| - sent once the error condition is detected.  Such

I omitted the dash from the suggestion.

>(5) (6)

Ack squared.

>(7) (8)  ... 'rational quotation'

Oh, alright but now the doc is inconsistent (other quotes are 
irrational) - squared.

>(9)

Went with the full-stop; I'm not a fan of semi-colons.

>(10)

>| server, the server ought to operate within the specification for an

Used the latter option - fewer words.

>(11)

7/8's squared response is now cubed.

>(12)

I went with something a little different

"...If the disruption was caused by a failure that proved to be
persistent, the AXFR client would be wise to not spend too many
resources trying to rebuild the connection.  ...

... Unfortunately, knowing which of the three cases above
(momentary disruption, persistent failure, policy) applies is not
possible with certainty, and can only be assessed by heuristics."

In the same spirit, but I used "proved to be" to indicate that the 
failure of the connection came at then onset of an event (like a 
router flaming out) and then later refer to "persistent failure." Or 
"persistent failure".)

>(13)  ... 'rational quotation' (#4)

Once squared, then cubed, now (umm) err, fourthed.

>(14) (15)

ack ack

>(16)

>to also use '[RFC2119]' in place of '[BCP14]'.

I kind of want to emphasize that it is also a BCP.  This kind of 
elevates the document above mere RFCdom.   In general, I've been 
trying to break the habit of using the RFC numbers as jargon to help 
remind me what it is (in general) we are doing.

Still, moved it to the normatives.

>b)

ack - wonder why that got messed up.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

Getting everything you want is easy if you don't want much.