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

Jeffrey Hutzelman <jhutz@cmu.edu> Fri, 17 September 2010 22:26 UTC

Return-Path: <jhutz@cmu.edu>
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 343723A6981 for <nscp@core3.amsl.com>; Fri, 17 Sep 2010 15:26:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.858
X-Spam-Level:
X-Spam-Status: No, score=-105.858 tagged_above=-999 required=5 tests=[AWL=-0.655, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 EmQK97ZBOrXu for <nscp@core3.amsl.com>; Fri, 17 Sep 2010 15:26:48 -0700 (PDT)
Received: from smtp03.srv.cs.cmu.edu (SMTP03.SRV.CS.CMU.EDU [128.2.217.198]) by core3.amsl.com (Postfix) with ESMTP id 29DAC3A6980 for <nscp@ietf.org>; Fri, 17 Sep 2010 15:26:48 -0700 (PDT)
Received: from MINBAR.FAC.CS.CMU.EDU (MINBAR.FAC.CS.CMU.EDU [128.2.216.42]) (authenticated bits=0) by smtp03.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id o8HMRAbg012357 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Sep 2010 18:27:10 -0400 (EDT)
Date: Fri, 17 Sep 2010 18:27:10 -0400
From: Jeffrey Hutzelman <jhutz@cmu.edu>
To: Paul Hoffman <paul.hoffman@vpnc.org>, OndXej Sur <ondrej@sury.org>
Message-ID: <076D7E021C1972DBD3D412B8@minbar.fac.cs.cmu.edu>
In-Reply-To: <p0624086fc8b998cb98d6@[10.20.30.158]>
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> <22489_1284679010_o8GNGnKr014689_AANLkTikkgZs3keRo0DcRCx9jSAbrFiHeLsyxE5ss 7hQ7@mail.gmail.com> <4C6A8B95E7FAF06E143D9425@minbar.fac.cs.cmu.edu> <p0624086fc8b998cb98d6@[10.20.30.158]>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
X-Scanned-By: mimedefang-cmuscs on 128.2.217.198
Cc: nscp@ietf.org, jhutz@cmu.edu
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: Fri, 17 Sep 2010 22:26:49 -0000

--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.

-- Jeff