datatracker.ietf.org
Sign In
Version 4.50, 2013-05-15
Report a bug

Network Configuration (netconf)

Group
Name: Network Configuration
Acronym:netconf
Area:Operations and Management Area (ops)
State: Active
Charter: charter-ietf-netconf-14-02 (Internal review)
Personnel
Chairs: Bert Wijnen <bertietf@bwijnen.net>
Mehmet Ersue <mehmet.ersue@nsn.com>
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/
Jabber Chat
Room Address:xmpp:netconf@jabber.ietf.org
Logs:http://jabber.ietf.org/logs/netconf/

In addition to the charter maintained by the IETF Secretariat, there is additional information about this working group on the Web at: Additional NETCONF Web Page

Charter for 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