Re: [nscp] Updating zone *content* in-scope or not?

Ondřej Surý <ondrej@sury.org> Mon, 20 September 2010 17:26 UTC

Return-Path: <ondrej@sury.org>
X-Original-To: nscp@core3.amsl.com
Delivered-To: nscp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D44023A6AE1 for <nscp@core3.amsl.com>; Mon, 20 Sep 2010 10:26:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.611
X-Spam-Level:
X-Spam-Status: No, score=-1.611 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wffeGDia+wDv for <nscp@core3.amsl.com>; Mon, 20 Sep 2010 10:26:08 -0700 (PDT)
Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id F160B3A6ACA for <nscp@ietf.org>; Mon, 20 Sep 2010 10:25:49 -0700 (PDT)
Received: by wyi11 with SMTP id 11so5453429wyi.31 for <nscp@ietf.org>; Mon, 20 Sep 2010 10:26:12 -0700 (PDT)
Received: by 10.227.132.146 with SMTP id b18mr2161671wbt.148.1285003572351; Mon, 20 Sep 2010 10:26:12 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.227.156.135 with HTTP; Mon, 20 Sep 2010 10:25:52 -0700 (PDT)
In-Reply-To: <076D7E021C1972DBD3D412B8@minbar.fac.cs.cmu.edu>
References: <4C9091C8.1030702@isc.org> <p062408d6c8b692e2c226@10.20.30.158> <A5289BAE-189D-4FF0-8AEC-2CCDC06D3B43@sinodun.com> <p062408dbc8b6aaf55b1a@10.20.30.158> <F41F5A3D292BA66474A70422@minbar.fac.cs.cmu.edu> <20100916130131.GA29091@nic.fr> <p0624081fc8b7e8b23cc0@10.20.30.158> <22r5gtcwtj.fsf@ziptop.autonomica.net> <p06240837c8b839e8f192@10.20.30.158> <22k4mlbb6k.fsf@ziptop.autonomica.net> <p0624083ac8b8499641a3@10.20.30.158> <4C6A8B95E7FAF06E143D9425@minbar.fac.cs.cmu.edu> <p0624086fc8b998cb98d6@10.20.30.158> <076D7E021C1972DBD3D412B8@minbar.fac.cs.cmu.edu>
From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= <ondrej@sury.org>
Date: Mon, 20 Sep 2010 19:25:52 +0200
Message-ID: <AANLkTikbeJSrc0Xp6-=AhWU1LYYcwtNHT2sRGhubVC==@mail.gmail.com>
To: Jeffrey Hutzelman <jhutz@cmu.edu>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: nscp@ietf.org, Paul Hoffman <paul.hoffman@vpnc.org>
Subject: Re: [nscp] Updating zone *content* in-scope or not?
X-BeenThere: nscp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS Nameserver control/configuration protocol discussion list <nscp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/nscp>, <mailto:nscp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nscp>
List-Post: <mailto:nscp@ietf.org>
List-Help: <mailto:nscp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nscp>, <mailto:nscp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Sep 2010 17:26:39 -0000

On Sat, Sep 18, 2010 at 00:27, Jeffrey Hutzelman <jhutz@cmu.edu>; wrote:
> --On Friday, September 17, 2010 03:15:25 PM -0700 Paul Hoffman
> <paul.hoffman@vpnc.org>; wrote:
>
>> At 6:06 PM -0400 9/17/10, Jeffrey Hutzelman wrote:
>>>
>>> --On Friday, September 17, 2010 01:15:13 AM +0200 OndÞej Sur˜
>>> <ondrej@sury.org>; wrote:
>>>
>>>>>> > That works for me, although it should probably be written into the
>>>>>>>
>>>>>>> charter.
>>>>>>
>>>>>> It should, definitely.
>>>>>
>>>>> If others agree that we want to possibly do this, but only after we
>>>>> have done the "new" work first, I'll write up proposed words. What do
>>>>> folks think?
>>>>
>>>> I agree that we should focus on new work first as proposed in previous
>>>> mails. My understanding of this group is that we basically want start
>>>> with protocol to add/remove/modify zone configuration remotely.
>>>
>>> I don't see managing zone content as necessarily wanting to be a
>>> separate protocol from adding zones and setting policy for them.  Let's
>>> not paint ourselves into a corner.
>>
>> I don't see us saying "we'll do that after we have settled on a protocol
>> and specified other management actions first" as "paint ourselves into a
>> corner". It's delaying stuff that can be a distraction.
>
> I'm fine with not working on that right now, and even with expressing that
> in the charter.  But I don't want to be having a discussion six months from
> now about whether a proposed protocol is flexible enough to support zone
> content management and have someone make the argument "it doesn't have to
> be; that's out of scope".
>
> As I see it, zone content management should be in scope for the
> to-be-developed protocol, and needs to be one of the things we consider as
> we design that protocol, even if actually defining how it works is not one
> of the first things we work on.

Well, you should probably explain why do you think we need
yet-another-protocol for managing zone contents.

There were voices against including it with reasoning (let's focus on
things with no alternative), so if you state that this should be
inside the charter, you should probably provide some arguments why
*XFR method is not sufficient and what will be the improvement against
AXFR/IXFR (+bunch of other out-of-band file transfer methods).

Ondrej
-- 
Ondřej Surý <ondrej@sury.org>;