WG Action: Rechartered Network Configuration (netconf)

The IESG <iesg-secretary@ietf.org> Thu, 20 September 2012 15:44 UTC

Return-Path: <iesg-secretary@ietf.org>
X-Original-To: ietf-announce@ietfa.amsl.com
Delivered-To: ietf-announce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D86021F8703; Thu, 20 Sep 2012 08:44:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.537
X-Spam-Level:
X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qHn4Ab66G+x3; Thu, 20 Sep 2012 08:44:22 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA9AC21F8712; Thu, 20 Sep 2012 08:44:22 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Subject: WG Action: Rechartered Network Configuration (netconf)
X-Test-IDTracker: no
X-IETF-IDTracker: 4.34
Message-ID: <20120920154422.13167.74604.idtracker@ietfa.amsl.com>
Date: Thu, 20 Sep 2012 08:44:22 -0700
Cc: netconf WG <netconf@ietf.org>
X-BeenThere: ietf-announce@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IETF announcement list. No discussions." <ietf-announce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf-announce>
List-Post: <mailto:ietf-announce@ietf.org>
List-Help: <mailto:ietf-announce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 20 Sep 2012 15:44:23 -0000

The Network Configuration (netconf) working group in the Operations and
Management Area of the IETF has been rechartered. For additional
information please contact the Area Directors or the WG Chairs.

Network Configuration (netconf)
------------------------------------------------
Current Status: Active Working Group

Chairs:
  Bert Wijnen <bertietf@bwijnen.net>
  Mehmet Ersue <mehmet.ersue@nsn.com>

Technical advisors:
  Tim Polk <tim.polk@nist.gov>

Assigned Area Director:
  Benoit Claise <bclaise@cisco.com>

Mailing list
  Address: netconf@ietf.org
  To Subscribe: https://www.ietf.org/mailman/listinfo/netconf
  Archive: http://www.ietf.org/mail-archive/web/netconf/

Charter of Working Group:

Configuration of networks of devices has become a critical requirement 
for operators in today's highly interconnected networks. Large and small 
operators alike have developed their own mechanisms or have used vendor 
specific mechanisms to transfer configuration data to and from a device 
and to examine device state information which may impact the 
configuration. Each of these mechanisms may be different in various 
aspects, such as session establishment, user authentication, 
configuration data exchange, and error responses.

The NETCONF protocol has the following characteristics:

- Provides retrieval mechanisms which can differentiate between 
configuration data and non-configuration data
- Is extensible enough so that vendors can provide access to all 
configuration data on the device using a single protocol
- Has a programmatic interface (avoids screen scraping and formatting-
related changes between releases)
- Uses an XML-based data representation, that can be easily manipulated 
using non-specialized XML manipulation tools.
- Supports integration with existing user authentication methods
- Supports integration with existing configuration database systems
- Supports multiple (e.g. candidate and running) data-stores to optimize 
configuration preparation and activation
- Supports network wide configuration transactions (with features such 
as locking and rollback capability)
- Runs over a secure transport; SSH is mandatory to implement while TLS, 
BEEP, and SOAP are optional transports.
- Provides support for asynchronous notifications.
- Supports an Access Control Model and a YANG module for configuring the 
Access Control parameters.
- Supports a YANG module for System Notifications

The NETCONF protocol is data modeling language independent, but YANG is 
the recommended NETCONF modeling language, which introduces advanced 
language features for configuration management.

In the current phase of NETCONF's incremental development the workgroup 
will focus on following items:

1. Advance NETCONF over TLS to be in-line with NETCONF 1.1 (i.e., update 
RFC 5539).

2. Based on the implementation, deployment experience and 
interoperability testing, the WG will produce a NETCONF status report. 
The result may be clarifications for RFC6241 and RFC6242 and addressing  
any reported errata.

Milestones:
  Done     - WG Last Call on rfc4741bis
  Done     - Send with-defaults to IESG for consideration as Proposed
Standard
  Done     - first WG draft (rev 00) on NACM posted
  Done     - rfc4741bis to IESG for consideration as Proposed Standard
  Done     - Send rfc4742bis to IESG for consideration as proposed
Standard
  Done     - first WG draft (rev 00) on NETCONF specific YANG modules
posted
  Done     - WGLC for NACM document
  Done     - WGLC for NETCONF specific notifications document
  Done     - submit NACM document to IESG for consideration as Proposed
Standard
  Done     - submit NETCONF specific notifications document to IESG for
consideration as Proposed Standard
  Sep 2012 - WGLC for rfc5539bis
  Sep 2012 - submit initial WG draft for rfc5539bis
  Oct 2012 - submit rfc5539bis to AD/IESG for consideration as Proposed
Standard
  Nov 2012 - Collect Implementation/Deployment reports for RFC6241 and
6242
  Dec 2012 - Initial I-D for RFC6241/6242 implementation/deployment
experience
  Jan 2013 - WGLC on RFC6241/6242 implementation/deployment experience
  Feb 2013 - possibly submit RFC6241/6242 implementation/deployment
experience doc to IESG for publication as Informational RFC
  Mar 2013 - Evaluate if more work needs to be done by NETCONF WG