[nscp] Welcome (and proposed charter)

Jelte Jansen <jelte@isc.org> Wed, 15 September 2010 09:28 UTC

Return-Path: <jelte@isc.org>
X-Original-To: nscp@core3.amsl.com
Delivered-To: nscp@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id C3C293A69AA for <nscp@core3.amsl.com>; Wed, 15 Sep 2010 02:28:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.056
X-Spam-Status: No, score=-102.056 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id Y0WRPYOJE9td for <nscp@core3.amsl.com>; Wed, 15 Sep 2010 02:28:30 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by core3.amsl.com (Postfix) with ESMTP id 285F83A6910 for <nscp@ietf.org>; Wed, 15 Sep 2010 02:28:27 -0700 (PDT)
Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id 6A13FC9423 for <nscp@ietf.org>; Wed, 15 Sep 2010 09:28:43 +0000 (UTC) (envelope-from jelte@isc.org)
Received: from [] (vhe-520087.sshn.net []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by farside.isc.org (Postfix) with ESMTP id E0E45E6030 for <nscp@ietf.org>; Wed, 15 Sep 2010 09:28:42 +0000 (UTC) (envelope-from jelte@isc.org)
Message-ID: <4C9091C8.1030702@isc.org>
Date: Wed, 15 Sep 2010 11:28:40 +0200
From: Jelte Jansen <jelte@isc.org>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20100826 Thunderbird/3.0.7
MIME-Version: 1.0
To: nscp@ietf.org
X-Enigmail-Version: 1.0.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Subject: [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 09:28:35 -0000

Hash: SHA1

First of all: Welcome, and thank you for joining, or at least not immediately
unsubscribing ;)

As you may or may not remember, we had an informal meeting at IETF 78 in
Maastricht, which I personally think went pretty well. I shall send out the
notes from that meeting shortly.

It has been a while since then, and I had hoped to get this list up before the
BoF Request had to be submitted, so we could discuss a charter to propose, which
is needed for a BoF request. However, getting the list to be set up took a bit
more time than expected (nearly 6 weeks, to be exact), and the deadline for
requesting BoF meetings at IETF 79 has passed by now.

Therefore, Stephen and I have written a proposed draft charter, which I sent in
with the BoF request. I'll add it below this message, and comments or
suggestions are very welcome. We do still have some time left before the next
IETF, so I trust we can get consensus on what it is we're trying to achieve here.


NSCP (draft) Charter
- --------------------

- ---------

Specify an interoperable mechanism to monitor, control and configure common
functionality of DNS nameservers.

Problem statement
- -----------------

The problem statement that this working group seeks to address can be
summarised as follows:

  Management of name servers for the Domain Name System (DNS) [RFC1034]
  [RFC1035] has traditionally been done using vendor-specific
  monitoring, configuration and control methods.  Although some service
  monitoring platforms can test the functionality of the DNS itself
  there is not an interoperable way to manage (monitor, control and
  configure) the internal aspects of a name server itself.

  Previous standardization work within the IETF resulted in the
  creation of two SNMP MIB modules [RFC1611] [RFC1612] but they failed
  to achieve significant implementation and deployment.  The perceived
  reasons behind the failure for the two MIB modules are further
  documented in [RFC3197].

(From draft-ietf-dnsop-name-server-management-reqs-04)

Despite the failure to achieve acceptance of an SNMP-based solution,
there is a perceived need for an interoperable way to manage nameservers,
something that led to the aforementioned draft being written to document
the requirements. Although this draft was written under the auspices of
the DNSOP working group, work to develop a solution is outside its charter.

The NSCP working group will develop a protocol to fulfill these
requirements.  The aims of the group will be to:

1. Review work to date (such as draft-dickinson-dnsop-nameserver-control-00,
which proposes a solution based on Netconf and Yang) and the available
technologies and choose a suitable technology on which to base future work.

2. Produce document(s) specifying a name server control protocol that address
the requirements of interoperable management of nameservers.
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/