Network Configuration

Document Proposed charter Network Configuration WG (netconf)
Title Network Configuration
Last updated 2017-03-28
State Internal review Rechartering
WG State Active
IESG Responsible AD Benoit Claise
Charter Edit AD Benoit Claise
Telechat date On agenda of 2017-04-13 IESG telechat
Needs a YES.
Send notices to (None)


The NETCONF Working Group, previously named after the NETCONF protocol, now
renamed as the NETwork CONFiguration Working Group, is responsible for the
development and maintenance of protocols for YANG data model driven management,
for the necessary framework where these protocols run, and for the YANG modules
that formalize protocol behavior and are required from protocol perspective. 

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).
The NETCONF protocol is data modeling language independent, but YANG (RFC 7950)
is the recommended NETCONF modeling language, which introduces advanced language
features for configuration management.

NETCONF WG recently finalized the development of RESTCONF protocol (RFC 8040)
which provides an interface over HTTPs for accessing data defined in YANG.
RESTCONF is based on the capabilities and uses the datastore concept defined in
the NETCONF protocol specification. In support of RESTCONF the YANG-Patch (RFC
8072) mechanism has been provided for applying patches to configuration
datastores. The YANG Module Library (RFC 7895) provides information about all
YANG modules used by a network management server.

Last but not least NETCONF and RESTCONF Call Home (RFC 8071) have been
developed, which enable a server to initiate a secure connection to a NETCONF or
RESTCONF client respectively.

In the current phase of NETCONF's incremental development the Working Groiup
will focus on following items:

1. Finalize the YANG data module for a system-level keystore mechanism,
which can be used to hold onto asymmetric private keys and certificates that are
trusted by the system advertising support for this module. Based on the known
dependencies this draft has the highest priority for the WG. 

2. Finalize Server and Client Configuration YANG modules for both NETCONF
and RESTCONF as well as the Client and Server Models for SSH and TLS. 

3. Finalize the Zero-touch provisioning for NETCONF or RESTCONF-based
Management as 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) 

4. Provide a revised version of RFC 6536 (NETCONF Access Control Model) by
adding support for RESTCONF and the YANG 1.1. constructs like "action" and the
"notification" statements. 

5. Provide a set of documents enabling advanced notification/ subscription
capabilities, which gracefully co-exist in a deployment of RFC 5277. The new
capabilities include e.g. transport independence, multiple dynamic and
configured subscriptions in a transport session. RFC 5277 will be obsoleted in
parallel to the publication of the new document set. Following specifications
will be addressed:
   - Protocol-neutral notification framework, i.e., explaining the concepts of
subscriptions, filters, subscription state notifications, replay, etc. and
defining the associated YANG data model, RPCs, etc.
   - Definition of notifications sent over NETCONF and HTTP. Examples for the
encoding of YANG notifications in XML and JSON will be given, considerations for
parallel support and implementation compatibility with RFC-5277 will be
   - Definition of notifications sent over RESTCONF and HTTP2 and how YANG
notifications are encoded in XML and JSON. Include specifics of call-home and
heartbeat for subscriptions.
   - The subscription and push mechanism for YANG datastores allowing subscriber
applications to request updates from a YANG datastore.
   - Define transport agnostic notification headers and provide the capability
to bundle YANG notifications into a single transport message. 

6. Based on the revised datastore concept work in NETMOD, provide a
revision for the NETCONF and RESTCONF protocols and the used datastore

7. Define capabilities for NETCONF and RESTCONF to support I2RS protocol
and ephemeral-state datastore requirements. 

    Based on the implementation, deployment experience and inter- operability
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

Goals and Milestones: 
May 2017 WGLC for Zero-touch configuration mechanism
Jun 2017 Submit Zero-touch configuration to AD/IESG for consideration as
Proposed Standard
May 2017 WGLC for system-level keystore mechanism
Jun 2017 Submit keystore mechanism to AD/IESG for consideration as Proposed
May 2017 WGLC for Server and Client models for NETCONF and RESTCONF
Jun 2017 Submit Server and Client Configuration models to AD/IESG for
consideration as Proposed Standard
May 2017 WGLC for Client and Server Models for SSH and TLS
Jun 2017 Submit Client and Server Models for SSH and TLS to AD/IESG for
consideration as Proposed Standard
Jun 2017 WGLC for RFC 6536bis (NETCONF Access Control Model)
Jul 2017 Submit RFC 6536bis to AD/IESG for consideration as Proposed Standard
Jun 2017 WGLC for advanced Notification/Subscription specifications
Jul 2017 Submit Notification/Subscription specifications to AD/IESG for
consideration as Proposed Standard

Proposed milestones

No milestones for charter found.