Subject: DNSEXT WGLC Summary: AXFR clarify

From: Ólafur Gudmundsson/DNSEXT co-chair <[email-masked]>
Date: Wed, 13 Nov 2002 11:54:43 -0500

Erik,

DNSEXT has completed it's review of this document and requests that
it be advanced to Proposed standard. This document updates RFC1035,
actually it fills in a under specified section.
Unfortunately the current version has expired, until author can post a
identical new version here is the last version
http://users.starpower.net/ogud/draft-ietf-dnsext-axfr-clarify-04.txt

thanks
         Olafur

>X-Sender:  (Unverified)
>X-Mailer: QUALCOMM Windows Eudora Version 5.1
>Date: Fri, 01 Mar 2002 01:57:16 -0500
>To: [email-masked]
>From: Ólafur Gudmundsson/DNSEXT co-chair <[email-masked]>
>Subject: DNSEXT WGLC Summary: AXFR-02.txt
>Sender: [email-masked]
>
>
>This last call concluded a long time ago, it is this chairs fault for
>not posting the consensus sooner, Sorry everyone.
>
>The working group rough consensus is to advance the document with minor
>changes as outlined below.
>There has been strong objection from certain well respected member of
>the working group.
>The main objections can be summarized in two major points:
>
>1. He objects to the restriction that all data go in answer section,
>he wants section agnostic rules.
>
>There is no technical reason why one is better or worse than the other.
>All implementations but ONE, put all AXFR data in ANSWER section, thus
>that is less disruptive to formalize.
>
>2. He objects to the restriction that AXFR MUST contain exactly the
>data that the master server loaded from zone file.
>Most early implementations did not comply with this rule, but some
>did, the old implementation that became the de-facto standard for DNS
>allowed data to leak between zones.
>This has certain beneficial behavior for delegations if data from
>children is better than parent, but has the following drawbacks
>     a. AXFR of the same version of a zone from two servers may
>        differ.
>     b. IXFR updates may fail due to preconditions not being true,
>        this was not explained in IXFR document.
>     c. Dynamic Update may fail due to preconditions (not explained
>        in Dynamic Update RFC).
>     d. Diagnosing problem is harder as answers differ between
>        Authorative servers.
>
>Since the AXFR last call concluded the working group had extensive
>discussion on similar issue: if DNSSEC servers could drop expired
>signatures.
>The working group expressed a strong and clear consensus on this
>issue:
>Authorative Servers MUST not change or discard any zone data, even if
>the server can determine data is wrong/bad.
>
>This counters objection #2.
>
>The Author has made all changes to the document that are needed, but
>the document has expired, Andreas please resubmit before deadline.

<snip suggested change that author and WG rejected>

>          Olafur

--
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/>