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

Brian Dickson <brian.peter.dickson@gmail.com> Sun, 19 June 2011 00:24 UTC

Return-Path: <brian.peter.dickson@gmail.com>
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 04F1711E8098 for <dnsext@ietfa.amsl.com>; Sat, 18 Jun 2011 17:24:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.524
X-Spam-Level:
X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 1nrKZ8A2ypLx for <dnsext@ietfa.amsl.com>; Sat, 18 Jun 2011 17:24:55 -0700 (PDT)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3709E11E807F for <dnsext@ietf.org>; Sat, 18 Jun 2011 17:24:55 -0700 (PDT)
Received: by fxm15 with SMTP id 15so531751fxm.31 for <dnsext@ietf.org>; Sat, 18 Jun 2011 17:24:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=wmwScCivWgG6HDXR99QXy2TI6ZSL36lFpolQxmIoe0k=; b=ClnaDEALqRQfsuFewmpGCIPaudyci0D80tnJHIqpxbcVUL63QiSxB0Av5f+vmm10oR b2CNSX0QvZgeNczsj1l0BCGonodIdc0PIkG2fPcQlZW/LQuJocJSxziGgvfKejO3Klxp r1hlnqCKhjX55tHu83IdnoPcVEu23GAtGuPlI=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=rHeflEbblpMuoBufGDK3AbE4PX8Lra8GJcJZAoJSAWiUS5ucZmQguF5gZXDbYsbS7U 5zMfBrUSqYKn72BSgdukMTt6vsEoobTgbclJvTS1hih+7Cg+4JtkbDh+r+nRRr1fVMz7 U9OKiVqBwGjUR1s5MBDrCmDb+ftEJL4VbaHE4=
MIME-Version: 1.0
Received: by 10.223.145.24 with SMTP id b24mr4108170fav.89.1308443094069; Sat, 18 Jun 2011 17:24:54 -0700 (PDT)
Received: by 10.223.123.79 with HTTP; Sat, 18 Jun 2011 17:24:54 -0700 (PDT)
In-Reply-To: <4DFC9C20.4030401@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> <a06240801ca2102b8b4f2@10.31.201.23> <BANLkTikoVVaXF2_LJ3KHm6P7oFpfC+n2tw@mail.gmail.com> <a06240801ca21246f76de@10.31.201.23> <BANLkTinVfuL0WEYwaycTaAnWDS9vYF5NjQ@mail.gmail.com> <4DFC9C20.4030401@necom830.hpcl.titech.ac.jp>
Date: Sat, 18 Jun 2011 20:24:54 -0400
Message-ID: <BANLkTimhLJfsmMe3AE34yLrOQ+zyZPBdgQ@mail.gmail.com>
From: Brian Dickson <brian.peter.dickson@gmail.com>
To: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
Content-Type: text/plain; charset="ISO-8859-1"
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: Sun, 19 Jun 2011 00:24:56 -0000

On Sat, Jun 18, 2011 at 8:37 AM, Masataka Ohta
<mohta@necom830.hpcl.titech.ac.jp> wrote:
> Brian Dickson wrote:
>
>> Now, presume some kind of command-and-control infrastructure,
>> directing/coordinating the activities and functions of the servers.
>
>> The MCP also keeps track of the Distribution Server Serial Numbers
>> (DSSN), along with the DS state (up/down/booting/whatever).
>> And the MCP keeps track of the Authority Server Serial Numbers (ASSN),
>> along with AS state (up/down/booting/whatever).
>
> If you want to have complex solutions for a simple problem,
> have a command-and-control infrastructure which can tell ASes
> from which DS to IXFR.

You are in fact correct.

The only problem is that, telling an AS to IXFR from a DS, does not
necessarily mean that the DS is able to provide the requested IXFR.
Yes, most of the time it should be able to, and will.

However, the rare time that it can't, IXFR-ONLY is important to have,
to avoid fallback.

> If you don't,
>
>> The MCP can tell each DS to purge its IXFR database.
>
> never purge purposelessly.

Exactly. Thank you for demonstrating that you understand what I wrote.
(I realize that understand is not synonymous with agree.)