WG Action: Rechartered Network Configuration (netconf)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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:
  Mahesh Jethanandani <mjethanandani@gmail.com>
  Mehmet Ersue <mehmet.ersue@nokia.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: https://mailarchive.ietf.org/arch/browse/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 (RFC 6241) provides mechanisms to install, 
manipulate, and delete the configuration of network devices. NETCONF is 
based on the secure transport (SSH is mandatory to implement while TLS 
is an optional transport) and uses an XML-based data representation. The 
NETCONF protocol is data modeling language independent, but YANG (RFC 
6020) 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. Provide a Server Configuration YANG module for both NETCONF and 
RESTCONF. 

  2. Develop RESTCONF, a protocol based on NETCONF in terms of 
capabilities, but over HTTPs and with some REST characteristics, for 
accessing YANG data in NETCONF datastores. An "ordered edit list" 
approach is needed (the YANG patch) to provide client developers with a 
simpler edit request format that can be more efficient and also allow 
more precise client control of the transaction procedure than existing 
mechanisms. The YANG patch operation, based on the  HTTP PATCH method, 
will be prepared in a separate draft.

In addition develop a YANG library, which identifies the information 
about all YANG modules used by a server. Furthermore develop a 
collection resource for the RESTCONF protocol to provide enhanced 
filtering features for the retrieval of data nodes with the GET method.

RESTCONF should not deviate from the NETCONF capabilities unless proper 
justification is provided and documented. The RESTCONF work will 
consider requirements suggested by the other working groups (for example 
I2RS).

  3. Develop a zero touch configuration document (a technique to 
establish a secure network management relationship between a newly 
delivered network device configured with just its factory default 
settings, and the Network Management System), specific to the NETCONF 
use case.

  4. Develop a subscription and push mechanism that allows client 
applications to request notifications for changes in the datastore. 
These updates will be pushed by the server to the client based on a 
subscription policy.

  5. Update RFC 6536 (NETCONF Access Control Model) to introduce access 
control rights associated with actions.

  6. Enhance RFC 5277 with the ability to delete subscriptions without 
closing the client session, to modify existing subscriptions, and to 
have multiple subscriptions on a established client session. These 
changes should not affect older clients that do not support these 
particular subscription requirements. The RPCs and the data models in 
RFC 5277 should be converted to YANG.

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.

Milestones:
  Done     - Submit RFC5539bis to AD/IESG for consideration as Proposed
Standard
  Done     - Submit NETCONF call home mechanism to AD/IESG for
consideration as Proposed Standard
  Oct 2015 - WGLC for RESTCONF, YANG patch operation and YANG Library
drafts
  Nov 2015 - Submit RESTCONF to AD/IESG for consideration as Proposed
Standard
  Jan 2016 - WGLC for RFC5277bis draft
  Jan 2016 - Submit RFC5277bis to AD/IESG for consideration as Proposed
Standard
  Jan 2016 - WGLC for YANG datastore push update draft
  Feb 2016 - Submit YANG datastore push update to AD/IESG for
consideration as Proposed Standard
  Feb 2016 - WGLC for RFC6536bis draft
  Feb 2016 - Submit RFC6536bis to AD/IESG for consideration as Proposed
Standard
  Feb 2016 - WGLC for zero touch configuration
  Feb 2016 - WGLC for RESTCONF Collection Resource draft
  Mar 2016 - Submit zero touch configuration to AD/IESG for consideration
as Proposed Standard
  Mar 2016 - Submit RESTCONF Collection to AD/IESG for consideration as
Proposed Standard
  Mar 2016 - WGLC for NETCONF server configuration data model
  Apr 2016 - Submit server configuration data model to AD/IESG for
consideration as Proposed Standard 





[Index of Archives]     [IETF]     [IETF Discussion]     [Linux Kernel]

  Powered by Linux