Subject: [dnsext] Fwd: New Version Notification for draft-kerr-ixfr-only-01

From: Ondřej Surý <[email-masked]>
Date: Fri, 26 Feb 2010 15:14:02 +0100

Hi,

we have incorporated all comments on -00.  Thanks to Mark, Alfred, 
Wouter, Joao, Joe and Jelte for those comments.

Ondrej

-------- Original Message --------
Subject: New Version Notification for draft-kerr-ixfr-only-01
Date: Fri, 26 Feb 2010 05:37:37 -0800 (PST)
From: IETF I-D Submission Tool <[email-masked]>
To: [email-masked]
CC: [email-masked]

A new version of I-D, draft-kerr-ixfr-only-01.txt has been successfuly 
submitted by Ondrej Sury and posted to the IETF repository.

Filename:	 draft-kerr-ixfr-only
Revision:	 01
Title:		 IXFR-ONLY to Prevent IXFR Fallback to AXFR
Creation_date:	 2010-02-26
WG ID:		 Independent Submission
Number_of_pages: 6

Abstract:
This documents proposes a new QTYPE (Query pseudo RRtype) for the
Domain Name System (DNS).  IXFR-ONLY is a variant of IXFR (RFC 1995)
that allows an authoritative server to incrementally update zone
content from another (primary) server without falling back from IXFR
to AXFR.  This way, alternate peers can be contacted more quickly and
convergence of zone content may be achieved much faster in important,
resilient operational scenarios.

The IETF Secretariat.

-- 
  Ondřej Surý
  vedoucí výzkumu/R&D manager
  -------------------------------------------
  CZ.NIC, z.s.p.o.    --    Laboratoře CZ.NIC
  Americka 23, 120 00 Praha 2, Czech Republic
  mailto:[email-masked]    http://nic.cz/
  tel:+420.222745110       fax:+420.222745112
  -------------------------------------------

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 27 Feb 2010 07:37:56 +0900

Ondrej Sury wrote:

You should learn not to use ISO8859 specific characters for
international communication.

> we have incorporated all comments on -00.

As the client SHOULD choose a server with the newest serial number,
there actually are not much room for server selection, which limits
applicability of your proposal.

>    If the IXFR server is is not able to reply with an IXFR it MUST NOT
>    reply with an AXFR unless AXFR result is smaller than IXFR result.

Though RFC1995 is not well written, its behaviour here is subtly
different between UDP and TCP and you should assume UDP.

Then, answer will unlikely be a entire zone content. You usually
get an SOA or a difference sequence.

Moreover, regardless of transport, QTYPE in answer of entire
zone is IXFR, not AXFR.

>    Instead, it MUST reply with RCODE CannotIXFR. (!FIXME)

No SOA serial number in the reply, even though the server may
have the newest?

>    If the IXFR result is larger than an AXFR, then an IXFR server MAY
>    reply with an AXFR result instead.  This is an optimization, and IXFR

The optimization is specified in RFC1995:

   Information about older versions should be purged if the total length
   of an IXFR response would be longer than that of an AXFR response.
   Given that the purpose of IXFR is to reduce AXFR overhead, this
   strategy is quite reasonable.  The strategy assures that the amount
   of storage required is at most twice that of the current zone
   information.

in a more useful way to bound server storage without your confusion
on QTYPE.

						Masataka Ohta