WG Action: Rechartered Network Configuration (netconf)

The IESG <iesg-secretary@ietf.org> Fri, 31 May 2013 16:06 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 0CD0F21F8624; Fri, 31 May 2013 09:06:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.558
X-Spam-Level:
X-Spam-Status: No, score=-102.558 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vqaZKdx2dGZ9; Fri, 31 May 2013 09:06:52 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AE39121F96F5; Fri, 31 May 2013 09:06:46 -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.50
Message-ID: <20130531160646.29335.19837.idtracker@ietfa.amsl.com>
Date: Fri, 31 May 2013 09:06:46 -0700
Cc: netconf WG <netconf@ietf.org>
X-BeenThere: ietf-announce@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: ietf@ietf.org
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: Fri, 31 May 2013 16:06:53 -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 WG

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

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:

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
is an optional transport.
  - 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.

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

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

1. Add call home mechanism for the mandatory SSH binding providing a
server-initiated session establishment.

2. Advance NETCONF over TLS to be in-line with NETCONF 1.1 (i.e., update
RFC 5539) and add the call home mechanism to provide a server-initiated
session establishment.

Milestones:
  May 2013 - Submit initial WG document on Reverse SSH
  Jun 2013 - WGLC for rfc5539bis
  Jul 2013 - WGLC for Reverse SSH
  Aug 2013 - Submit rfc5539bis to AD/IESG for consideration as Proposed
Standard
  Aug 2013 - Submit SSH binding to AD/IESG for consideration as Proposed
Standard