Re: [dnsext] Fwd: New Version Notification for draft-ah-dnsext-rfc1995bis-ixfr-02

Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Fri, 17 June 2011 01:08 UTC

Return-Path: <mohta@necom830.hpcl.titech.ac.jp>
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B64811E80F8 for <dnsext@ietfa.amsl.com>; Thu, 16 Jun 2011 18:08:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.09
X-Spam-Level:
X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h8+vc3i2Rtca for <dnsext@ietfa.amsl.com>; Thu, 16 Jun 2011 18:08:47 -0700 (PDT)
Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietfa.amsl.com (Postfix) with SMTP id 5BA9011E80CC for <dnsext@ietf.org>; Thu, 16 Jun 2011 18:08:47 -0700 (PDT)
Received: (qmail 73381 invoked from network); 17 Jun 2011 01:17:02 -0000
Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 17 Jun 2011 01:17:02 -0000
Message-ID: <4DFAA8CC.5040802@necom830.hpcl.titech.ac.jp>
Date: Fri, 17 Jun 2011 10:07:24 +0900
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: dnsext@ietf.org
References: <4DB81069.3080404@nic.cz> <4DF9B5BD.7010900@nic.cz> <a06240803ca1fd7525c50@10.31.201.23> <BANLkTinjRDHyKH-tLEoejodXb2+7qQLO7w@mail.gmail.com> <20110617001740.D2B9F10D52C8@drugs.dv.isc.org>
In-Reply-To: <20110617001740.D2B9F10D52C8@drugs.dv.isc.org>
Content-Type: text/plain; charset="ISO-2022-JP"
Content-Transfer-Encoding: 7bit
Subject: Re: [dnsext] Fwd: New Version Notification for draft-ah-dnsext-rfc1995bis-ixfr-02
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsext>, <mailto:dnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsext>
List-Post: <mailto:dnsext@ietf.org>
List-Help: <mailto:dnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 Jun 2011 01:08:48 -0000

Mark Andrews wrote:

>      the problem is that in some ixfr implementations there is no
> way to turn off, the optional, delta consolidation.

That's not a problem. However, if the implementations blindly
consolidate ignoring the paragraph:

   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.

they are poor implementations to be avoided by rational operators,
unless there are fair reasons of the ignorance.

Consolidations following the paragraph above may still cause
transient inefficiency. But, does that matter and worth protocol
extensions and additional operational complexities?

						Masataka Ohta