Subject: Re: [dnsext] I-D ACTION:draft-ietf-dnsext-axfr-clarify-12.txt

From: Alfred Hönes <[email-masked]>
Date: Tue, 8 Dec 2009 02:00:24 +0100 (MEZ)

At Mon, 7 Dec 2009 15:45:02 -0800 (PST), [email-masked] wrote:

> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the DNS Extensions Working Group of the IETF.
>
>         Title           : DNS Zone Transfer Protocol (AXFR)
>         Author(s)       : E. Lewis, A. Hoenes
>         Filename        : draft-ietf-dnsext-axfr-clarify-12.txt
>         Pages           : 28
>         Date            : 2009-12-6
>
> The Domain Name System standard mechanisms for maintaining coherent
>    servers for a zone consist of three elements.  One mechanism is the
>    Authoritative Transfer (AXFR) defined in RFC 1034 and RFC 1035.
>    The definition of AXFR has proven insufficient in detail, thereby
>    forcing implementations intended to be compliant to make assumptions,
>    impeding interoperability.  Yet today we have a satisfactory set of
>    implementations that do interoperate.  This document is a new
>    definition of AXFR -- new in the sense that is it recording an
>    accurate definition of an interoperable AXFR mechanism.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-dnsext-axfr-clarify-12.txt
>
> ...

This draft version has been prepared to make the document ready
for WGLC.  Details are listed below.

  Alfred.

Edit log for draft-ietf-dnsext-axfr-clarify-11  -->  -12
========================================================

Main topics of edits since -11 draft version:
- addressed editorial nits from Alfred's message (April 1, 2009)
  to namedroppers (cf. Ed Lewis' response on namedroppers of April 2)
- addressed Andrew's WG chair review comments, including idnits results
  (May 27 and May 29, 2009)
- improved adherence to I-D Guidelines and RFC style guide
- adopted capitalization of RCODE values from IANA registry
- added Alfred as document editor

In detail (excluding nits):

General:
- updated draft version, publication and expiry dates
- added pre-5378 boilerplate text, Abstract now first
- added pagination using standard page header and footer patterns
- reformatted all text to indentation stepwidth 3 and 72 column format
- reformatted section headings to adhere to RFC styleguide
- modified numbering scheme for Notes to better match RFC styleguide
- added Table of Contents
- capitalized DNS message section names for clarity and better
  distinguishing them from plain English words ("Additional", etc.)
- made terminology consistent with RFC 1035: Query -> Question section

Sections 1, 1.1, 1.2
- added 'management level' statement of goal of the memo to Sect.1
  (new 2nd para) and link to "Updates" clause in the front matter
- moved feedback editorial remark to behind Authors Addresses,
  adding RFC Editor note to it
- wordsmithing in 2nd para of 1.1 to avoid dangling initial
  capitalization conflict
- moved definition of "General purpose DNS implementation" and
  "Turnkey DNS implementation" from mid-section 1.2 to end of 1.1
- reworked 1st para in 1.1 based on WG chair comments, avoiding
  unnecessary text repetition
- wordsmithing of last para of 1.2 to avoid normative language, and
  delete "editorial note to readers" (as per WG chair review)

Sections 1.3 and 1.4
- wordsmithing of 1.3 to avoid allusion of IXFR / NOTIFY coverage
  (as per WG chair review); however, left para in text because it
  makes comprehensive note of a change in paradigm important for
  many folks (including IESG?) that would otherwise be somehow
  hidden in the bulk of the text
- same for 1st para of 1.4
- break xxl sentence apart in last para of 1.4

Section 2
- updated informative ref for rsa-sha2 draft to RFC 5702
- changed ref tag for dnssec-bis-updates draft
- integrated single remaining ref to an I-D with the list of RFCs
  updating the DNS message format, and wordsmithed the paragraph below
  this list to reflect this change and reduce perceived allusion of
  normative references
- split list of documents into two, for Basic DNS and DNSSEC;
  this should give better guidance to the reader, and it allows
  to get rid of the DNSSEC document list in 2.2.2 that would have
  needed to be indented with the enclosing Note, causing very
  unpleasant line folding
- added reproduction of DNS message header synopsis from RFC 5395
  as a convenience for the reader, and because the text already said
  that the memo makes use of the field names therein; rephrased the
  surrounding text to accommodate the addition
- added a sentence on UDP message size (and EDNS0, giving it a ref)
  pointing to Section 4 to make the penultimate para appear less OOTB;
  simplified trailing sentence on EDNS0 irrelavance for TCP

Section 2.1

Section 2.1.1
- structured Header values table, added more informative text to
  quickly inform the reader
- in Note a) :  added xrefs to sections 4 and 2.2.2
- introduced mnemonic 'n/a' and 'mbz' shorthands for better guidance
  of readers

Section 2.1.2
- added "a single RR" to justify QDCOUNT=1

Sections 2.1.3 and 2.1.4
- language improvement (WG chair comments)

Section 2.1.5
- wordsmithed 1st para to address WG chair comments
- same for 2nd para, but escaped to reducing use of "ought to"
- wordsmithed 3rd para to address WG chair comments

Section 2.2
- made explicit the alternative for subsequent response messages
  to contain an empty Question section  (end of 2nd para)
- 3rd & 4th para clarified as per msg exchange Apr 1/2, 2009
- simplified text in 3rd para a bit to avoid over-use of "MUST"
- whole section is written from the perspective of the server;
  therefore last para re-written in that vein

Section 2.2.2
- added intro sentence similar to 2.1.1
- structured Header values table, added more informative text to
  quickly inform the reader (as in 2.1.1)

Section 2.2.3
- language improvement (WG chair comments)
- case of error message spelled out once again for completeness
- open issue: "MAY" in the 5th line: contradicts FR RFC !

Section 2.2.6
- some wordsmithing for clarity, and to avoid word repetition

Section 3
- added clarification regarding "continually regenerated"
  DNS database, as requested by WG chair review

Section 3.1
- refer to "zone" (in singular form) in last para

Section 3.2
- simplified wording on DNSSEC RRs
- typos corrected in 3rd & 4th "Informally:" bullet
- in response to WG Chair review wrt DNSSEC related history:
  The intent is to point the reader to the (sometimes confusing)
  fact that RFC 2181 (still valid and important in other parts)
  is entirely outdated with respect to DNSSEC.
  RFC 2181 is neither Obsoleted nor Historic.
  This argument would perhaps become moot by the event of a 2181bis!
  New text: "... which parts of RFC 2181 now in fact are historical."
- in response to WG Chair concerns:
  expanded repeated verbiage like  "authoritative part of the zone"
  to "part of the authoritative data of the zone" and similar
- in response to WG Chair concerns:
  the description of two scenarios for inconsistent delegation points
  has been slightly reworded, but left in the draft to provide
  background information for the recovery strategy specified
  subsequently, giving the reader the opportunity to verify that
  the outcome of that specification for such scenarios is resaonable
  (contrary to some opinions raised during the discussion calling
  for a self-fixing mechanism for inconsistencies in zone data to
  be built into the AXFR protocol).
- 2nd-to-last para: "also" conflict resolved using "as well" instead

Section 3.3

Section 3.4

Section 4
- wordsmithing of 2nd and 3rd para to address WG Chair concerns,
  split long sentence
- 4th para: rewritten for the same concerns
- last para: moved to 4.2

Section 4.1
- clarified language in 1st para to address WG Chair concerns
- clarified language in 2nd para (per msg exchange Apr 1/2, 2009);
  changed "given here" to "given below" to address WG Chair concerns

Section 4.1.1
- improved wording in 3rd para (per msg exchange Apr 1/2, 2009)
- 2nd para: MAY seemed to be too strong; the sentence describes
  the only possibility for last resort; so changed to "can"
- clarified 3rd para (per msg exchange Apr 1/2, 2009)

Section 4.1.2
- small language improvement for clarification in 1st para

Section 4.2
- moved clause regarding "future perspective" of AXFR over UDP
  from 4. into this section and text adapted to accommodate the move

Section 5
- rephrased second part of 1st para to accomodate WG chair comments

Section 6
- expanded "not in" to "not present in" for clarity, near the end of
  the 2nd para

Section 7
- typos corrected
- expanded "the earlier sections" to "the relevant earlier sections"
  near the end of the 1st para
- 2nd para (WG Chair review concern): "turnkey implementations" is ok;
  the definition of this term now has been moved into 1.1 (see above)
- wording improved in last para (per WG chair comments), yet
  avoided immediate word repetition

Section 7.1
- wording improved in 1st para (per WG chair comments)
- addressed WG chair comments for 2nd para, using "necessity"
- lost words restored from backup (at end of section)

Section 9
- added RFC-Ed note

Section 10
- regarding IDNA documents: proactively added "or its successor(s)"

Section 11
- acknowledgments updated

Section 12
- reworded 1st sentence to cover the kept [BCP14] ref. as well

Sections 12.1/2
- RFC 2119 promoted to Normative
- updated I-D refs (RFC 5702 published), promoted to Normative
- collation order by ascending RFC number restored
- on behalf of RFC 5395, IANA has outdated the DNS Header Flags
  registry [DNSFLGS] and encorporated it into the DNS Parameters
  registry [DNSVALS]; hence unified references to IANA
- demoted IANA ref. to Informative

Open issue:
  The bulk of documents listed in Section 2 are not needed in other
  parts of the memo; this bulk ok Normative Refs seems to be
  excessive; should these be demoted to Informative?

[]

---

From: Alfred Hönes <[email-masked]>
Date: Tue, 8 Dec 2009 02:05:19 +0100 (MEZ)

In the previous messsage, a minor open issue for axfr-clarify-12

>   excessive; should these be demoted to Informative?

Here is my personal view:

Opinions in the IESG largely diverge; there are 15 experts on
Normative vs. Informative but only a few DNS experts; so maybe
granting the IESG a few DISCUSSes on this detail will help them
adding their 2 ct. to the document without more significantly
impacting the document progress.  :-)

  Alfred.