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. Develop the call home mechanism for the mandatory SSH binding (Reverse SSH) providing a server-initiated session establishment. 2. Develop a zero touch configuration document, specific the NETCONF use case. 3. 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. 4. Combine the server configuration data models from Reverse SSH and RFC5539bis drafts in a separate call home YANG module. 5. Develop a RESTful interface (RESTCONF) for accessing YANG data using the datastores defined in NETCONF. 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. RESTCONF should not deviate from NETCONF unless proper justifications is provided and documented. Goals and Milestones: Feb 2014 - Submit initial WG drafts for RESTCONF and patch operation as WG item Feb 2014 - Submit initial WG drafts for zero touch configuration as WG item Feb 2014 - Submit initial WG draft for call home YANG module as WG item Apr 2014 - WGLC for RFC5539bis Apr 2014 - WGLC for Reverse SSH Apr 2014 - WGLC for call home YANG module Apr 2014 - WGLC for zero touch configuration Apr 2014 - WGLC for NETCONF server configuration data model May 2014 - Submit Reverse SSH and zero touch configuration to AD/IESG for consideration as Proposed Standard May 2014 - Submit RFC5539bis to AD/IESG for consideration as Proposed Standard May 2014 - Submit zero touch configuration to AD/IESG for consideration as Proposed Standard May 2014 - Submit call home YANG module to AD/IESG for consideration as Proposed Standard Jun 2014 - WGLC for RESTCONF and patch operation drafts Aug 2014 - Submit RESTCONF to AD/IESG for consideration as Proposed Standard