IETF Logo Mail Archive

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

Edward Lewis <Ed.Lewis@neustar.biz> Fri, 17 June 2011 13:54 UTC

Return-Path: <Ed.Lewis@neustar.biz>
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 96F5211E815C for <dnsext@ietfa.amsl.com>; Fri, 17 Jun 2011 06:54:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.045
X-Spam-Level:
X-Spam-Status: No, score=-106.045 tagged_above=-999 required=5 tests=[AWL=0.554, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 EiQrl-IcxlKW for <dnsext@ietfa.amsl.com>; Fri, 17 Jun 2011 06:54:09 -0700 (PDT)
Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id DFAA711E8139 for <dnsext@ietf.org>; Fri, 17 Jun 2011 06:54:08 -0700 (PDT)
Received: from work-laptop-2 (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p5HDs0gA002754; Fri, 17 Jun 2011 09:54:04 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz)
Received: from [10.31.201.23] by work-laptop-2 (PGP Universal service); Fri, 17 Jun 2011 09:54:07 -0400
X-PGP-Universal: processed; by work-laptop-2 on Fri, 17 Jun 2011 09:54:07 -0400
Mime-Version: 1.0
Message-Id: <a06240803ca210bdad8ec@[10.31.201.23]>
In-Reply-To: <4DFAB161.8030108@necom830.hpcl.titech.ac.jp>
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> <4DFAA8CC.5040802@necom830.hpcl.titech.ac.jp> <20110617012827.5A8AD10D5D42@drugs.dv.isc.org> <4DFAB161.8030108@necom830.hpcl.titech.ac.jp>
Date: Fri, 17 Jun 2011 09:53:57 -0400
To: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
From: Edward Lewis <Ed.Lewis@neustar.biz>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4
Cc: dnsext@ietf.org
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 13:54:09 -0000

At 10:44 +0900 6/17/11, Masataka Ohta wrote:
>Mark Andrews wrote:
>
>>  The problem is sending a AXFR style
>>  response when you don't have the requested starting serial but do
>>  have a potential starting serial that is before the requested
>>  starting serial.
>
>I wrote:
>
>>>  Consolidations following the paragraph above may still cause
>>>  transient inefficiency. But, does that matter and worth protocol
>>>  extensions and additional operational complexities?

I'm arguing the same as Ohta-san.

I think RFC 1995's description is pretty clear, and whatever 
IXFR-only is trying to solve is just to address what implementations 
have done at the cost of muddying up the protocol further.

I had been thinking of requesting IXFR be updated for DNSSEC, but 
even that idea is really just about hardening implementations, not 
changing the IXFR protocol at all.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

I'm overly entertained.

v2.23.0 | Report a Bug | By Email