Re: [dnsext] draft-ah-dnsext-rfc1995bis-ixfr-03 -- changes since -02

Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Sun, 11 March 2012 13:38 UTC

Return-Path: <dnsext-bounces@ietf.org>
X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org
Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13AE221F8630; Sun, 11 Mar 2012 06:38:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1331473109; bh=CKNBTWjUtf8Jl8le2c8DytfXX4UqeaxV+NDEqIw6QMc=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Transfer-Encoding:Content-Type:Sender; b=H5do1jhWxlnIDwbJBb38ArV4mt6sHsZg3B4nW4uZP8tF2pGGu+NIhJNPxTEVC8q+V ejkUKO9jbdUfZyrsFiY624f9CISo580GAp1ENcX7dV44ee25sgKFhS5KzJ83UEr3ow gcawP1cvmlNymxVlt1tW8gTdkfQ4vdTh6gmEvtZU=
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 56EED21F8630 for <dnsext@ietfa.amsl.com>; Sun, 11 Mar 2012 06:38:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.175
X-Spam-Level:
X-Spam-Status: No, score=0.175 tagged_above=-999 required=5 tests=[AWL=-0.035, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0gvsyMAAE0fA for <dnsext@ietfa.amsl.com>; Sun, 11 Mar 2012 06:38:27 -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 67A5B21F861A for <dnsext@ietf.org>; Sun, 11 Mar 2012 06:38:24 -0700 (PDT)
Received: (qmail 46478 invoked from network); 11 Mar 2012 14:01:03 -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; 11 Mar 2012 14:01:03 -0000
Message-ID: <4F5CAA8A.6010406@necom830.hpcl.titech.ac.jp>
Date: Sun, 11 Mar 2012 22:37:14 +0900
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: Alfred � <ah@TR-Sys.de>
References: <201203092033.VAA02764@TR-Sys.de>
In-Reply-To: <201203092033.VAA02764@TR-Sys.de>
Cc: dnsext@ietf.org
Subject: Re: [dnsext] draft-ah-dnsext-rfc1995bis-ixfr-03 -- changes since -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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: dnsext-bounces@ietf.org
Errors-To: dnsext-bounces@ietf.org

Alfred wrote:

> There have been complaints that the draft already shows much too
> much context and it should better be stripped down to a pure
> specification document ignoring any applicability questions.

That's not mine.

The problem I saw was that the draft lacked use case.

> Are you now saying it should also present some kind of detailed
> use case analysis or applicability statement, far beyond what is
> said in Section 1 and Appendix A (motivation -- by existing use
> cases -- for IXFR-ONLY)?

I can see no meaningful use cases in Section 1 nor Appendix A.

While your draft seemingly assumes zones should be purposelessly
condensed, RFC1995 already says:

    But, this feature may not be so useful if an IXFR client has access
    to two IXFR servers: A and B, with inconsistent condensation results.

and

    Information about older versions should be purged if the total length
    of an IXFR response would be longer than that of an AXFR response.

that's why I can't see any meaningful use cases

> I fear this would likely disqualify the document for Standards Track.

Not even BCP, because RFC1995 already stated enough as a practical BCP.

> Do you want that?

Want what?

							Masataka Ohta
_______________________________________________
dnsext mailing list
dnsext@ietf.org
https://www.ietf.org/mailman/listinfo/dnsext