Network Configuration (netconf) ------------------------------- Charter Current Status: Active Chairs: Bert Wijnen Mehmet Ersue Operations and Management Area Directors: Ronald Bonica Benoit Claise Operations and Management Area Advisor: Benoit Claise Mailing Lists: General Discussion: netconf@ietf.org To Subscribe: netconf-request@ietf.org or: https://www.ietf.org/mailman/listinfo/netconf Archive: http://www.ietf.org/mail-archive/web/netconf/ Description of Working Group: Configuration of networks of devices has become a critical requirement for operators in today's highly interoperable networks. Operators from large to small have developed their own mechanisms or used vendor specific mechanisms to transfer configuration data to and from a device, and for examining 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 Working Group has produced a protocol suitable for network configuration, with 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 has been designed independent of the data modeling language. The IETF recommends to use YANG as the NETCONF modeling language, which introduces advanced language features for configuration management. In the current phase of the incremental development of NETCONF the workgroup will focus on following items: 1. Advance NETCONF over TLS to be in-line with NETCONF 1:1. This means that RFC5593 needs to be updated. 2. To enable an implementation with a reduced code-size there seems to be a need for a modular NETCONF solution (Netconf-Lite), which can be used e.g. for an incremental deployment or in constrained devices with less memory. Netconf-Light does not aim to address new operational needs of constrained devices currently discussed in the Coman activity. The WG will create a document defining the minimal base of features for such a standard. 3. RFC5277 (Netconf Event Notifications) was written before the YANG modeling language existed. The WG will "YANGify" that RFC, so that we have a proper YANG module for the Netconf Event Notifications. 4. Based on [the] implementation and deployment experience, the WG will document the status of NETCONF in order to advance the base documents (at least RFC6241 and RFC6241) on the standards track. Goals and Milestones: done - Send with-defaults to IESG for consideration as Proposed Standard done - WG Last Call on rfc4741bis 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 NACM posted 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 aug 2012 - submit initial WG draft for rfc5539bis aug 2012 - submit initial WG draft for rfc5277bis aug 2012 - submit initial WG draft for Netconf Lite sep 2012 - WGLC for rfc5539bis okt 2012 - submit rfc5539bis to AD/IESG for consideration as Proposed Standard okt 2012 - WGLC for rfc5277bis okt 2012 - Collect Implementation/Deployment reports for RFC6241 and 6242 nov 2012 - Seconf WGLC for rfc5277bis (if needed) nov 2012 - WGLC for Netconf Lite nov 2012 - Initial I-D for RFC6241/6242 implementation/deployment experience dec 2012 - submit rfc5277bis to AD/IESG for consideration as Proposed Standard jan 2013 - second WGLC for Netconf Lite (if needed) jan 2013 - WGLC on RFC6241/6242 document to advance on standards track feb 2013 - submit Netconf Lite to AD/IESG for consideration as Proposed Standard feb 2013 - submit request to AD/IESG to advance RFC6241/6242 on Standards Track