Re: [dnsext] I-D ACTION:draft-ietf-dnsext-axfr-clarify-12.txt
Alfred Hönes <ah@TR-Sys.de> Tue, 08 December 2009 01:08 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 1CADD28C1A6; Mon, 7 Dec 2009 17:08:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.218
X-Spam-Level: ***
X-Spam-Status: No, score=3.218 tagged_above=-999 required=5 tests=[AWL=-1.032, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1]
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 T61KniFJpxql; Mon, 7 Dec 2009 17:08:04 -0800 (PST)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 58C4F28C18F; Mon, 7 Dec 2009 17:08:03 -0800 (PST)
Received: from majordom by psg.com with local (Exim 4.70 (FreeBSD)) (envelope-from <owner-namedroppers@ops.ietf.org>) id 1NHoSO-0001oA-Sa for namedroppers-data0@psg.com; Tue, 08 Dec 2009 01:01:36 +0000
Received: from [213.178.172.147] (helo=TR-Sys.de) by psg.com with esmtp (Exim 4.70 (FreeBSD)) (envelope-from <A.Hoenes@TR-Sys.de>) id 1NHoSK-0001nh-7l for Namedroppers@ops.ietf.org; Tue, 08 Dec 2009 01:01:33 +0000
Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA282874025; Tue, 8 Dec 2009 02:00:25 +0100
Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id CAA02168; Tue, 8 Dec 2009 02:00:24 +0100 (MEZ)
From: Alfred Hönes <ah@TR-Sys.de>
Message-Id: <200912080100.CAA02168@TR-Sys.de>
Subject: Re: [dnsext] I-D ACTION:draft-ietf-dnsext-axfr-clarify-12.txt
To: Namedroppers@ops.ietf.org
Date: Tue, 08 Dec 2009 02:00:24 +0100
X-Mailer: ELM [$Revision: 1.17.214.3 $]
Mime-Version: 1.0
Content-Type: text/plain; charset="hp-roman8"
Content-Transfer-Encoding: 7bit
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/>
At Mon, 7 Dec 2009 15:45:02 -0800 (PST), internet-drafts@ietf.org 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? []
- [dnsext] I-D ACTION:draft-ietf-dnsext-axfr-clarif… Internet-Drafts
- Re: [dnsext] I-D ACTION:draft-ietf-dnsext-axfr-cl… Alfred Hönes
- Re: [dnsext] I-D ACTION:draft-ietf-dnsext-axfr-cl… Alfred Hönes