Re: [nscp] Welcome (and proposed charter)

jad <jad@sinodun.com> Wed, 15 September 2010 17:02 UTC

Return-Path: <jad@sinodun.com>
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 B01763A69ED for <nscp@core3.amsl.com>; Wed, 15 Sep 2010 10:02:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.165
X-Spam-Level:
X-Spam-Status: No, score=-2.165 tagged_above=-999 required=5 tests=[AWL=1.435, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 6-xfN01XZg-s for <nscp@core3.amsl.com>; Wed, 15 Sep 2010 10:02:53 -0700 (PDT)
Received: from cpanelsmarthost2.zen.co.uk (cpanelsmarthost2.zen.co.uk [82.71.204.226]) by core3.amsl.com (Postfix) with ESMTP id B12A83A690E for <nscp@ietf.org>; Wed, 15 Sep 2010 10:02:53 -0700 (PDT)
Received: from [88.98.24.67] (helo=shcp01.hosting.zen.net.uk) by cpanelsmarthost2.zen.co.uk with esmtp (Exim 4.69) (envelope-from <jad@sinodun.com>) id 1OvvOA-0001Gi-Tt for nscp@ietf.org; Wed, 15 Sep 2010 17:03:18 +0000
Received: from 82-68-198-190.dsl.in-addr.zen.co.uk ([82.68.198.190] helo=andromeda.sinodun.com) by shcp01.hosting.zen.net.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from <jad@sinodun.com>) id 1OvvO5-00048e-SK; Wed, 15 Sep 2010 18:03:14 +0100
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=us-ascii
From: jad <jad@sinodun.com>
In-Reply-To: <p062408dbc8b6aaf55b1a@[10.20.30.158]>
Date: Wed, 15 Sep 2010 18:03:12 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <1F675FEC-C6FE-480D-A598-44BCBFCD46C0@sinodun.com>
References: <4C9091C8.1030702@isc.org> <p062408d6c8b692e2c226@[10.20.30.158]> <A5289BAE-189D-4FF0-8AEC-2CCDC06D3B43@sinodun.com> <p062408dbc8b6aaf55b1a@[10.20.30.158]>
To: Paul Hoffman <paul.hoffman@vpnc.org>
X-Mailer: Apple Mail (2.1081)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - shcp01.hosting.zen.net.uk
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - sinodun.com
Cc: nscp@ietf.org
Subject: Re: [nscp] Welcome (and proposed charter)
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: Wed, 15 Sep 2010 17:02:54 -0000

On Sep 15, 2010, at 5:57 PM, Paul Hoffman wrote:

> At 5:53 PM +0100 9/15/10, jad wrote:
>> On Sep 15, 2010, at 4:30 PM, Paul Hoffman wrote:
>> 
>>> At 11:28 AM +0200 9/15/10, Jelte Jansen wrote:
>>>> Objective
>>>> - ---------
>>>> 
>>>> Specify an interoperable mechanism to monitor, control and configure common
>>>> functionality of DNS nameservers.
>>> 
>>> Probably the most common functionality is updating zone files. Is this in scope, out of scope, or not determined yet? There is clamoring for secure updating that is easier to configure and than SIG0 and its friends, and almost no one cares if this is done in the DNS protocol, so this WG might or might not be the right place for that.
>> 
>> Our thinking at the time was that nscp would need some limited mechanism to create new zones. You need at least an SOA and filename after all. However, there are many ways that the zone data could be inserted into the zone. Dynamic updates,. AXFR, checkout from subversion, database.....
>> 
>> So I do think that the bulk creation/insertion of zone data is out of scope. However, configuration of the nameserver so that it knows how to get that data is in scope.
> 
> If you think it is out of scope, the charter needs to day that.
> 
> OTOH, why not allow it using the same mechanism that is being used for the rest of the control? That is, don't prevent "Dynamic updates,. AXFR, checkout from subversion, database.....", but specify how to do it the same way as the rest of the control?

Sure, I wouldn't prevent nscp from updating zones. But I don't think nscp would be the best way or my first choice. So maybe saying "out of scope" is a bit strong.

John