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
