Subject: [Netconf] WG Action: Rechartered Network Configuration (netconf)

From: The IESG <[email-masked]>
Date: Fri, 09 Jun 2017 10:22:22 -0700

The Network Configuration (netconf) WG 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 WG

Chairs:
  Mahesh Jethanandani <[email-masked]>
  Mehmet Ersue <[email-masked]>

Assigned Area Director:
  Benoit Claise <[email-masked]>

Operations and Management Area Directors:
  Warren Kumari <[email-masked]>
  Benoit Claise <[email-masked]>

Mailing list:
  Address: [email-masked]
  To subscribe: https://www.ietf.org/mailman/listinfo/netconf
  Archive: https://mailarchive.ietf.org/arch/browse/netconf/

Group page: https://datatracker.ietf.org/group/netconf/

Charter: https://datatracker.ietf.org/doc/charter-ietf-netconf/

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 a
protocol perspective.

The NETCONF protocol (RFC 6241) provides mechanisms to install, manipulate,
and delete the configuration of network devices. NETCONF is based on 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 data modeling language, which introduces
advanced language features for configuration management.

The NETCONF WG published the RESTCONF protocol (RFC 8040) which provides an
interface over HTTPS for accessing data defined in YANG. RESTCONF is based on
the capabilities of, 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 Group
will focus on following items:

1. Finalize the YANG data module for a system-level keystore mechanism, which
can be used to hold asymmetric private keys and certificates that are trusted
by the system advertising support for this module. Based on the known
dependencies (multiple NETCONF documents), 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 NETCONF Access Control Model (RFC 6536) by
adding support for RESTCONF and for YANG 1.1 constructs like "action" and the
(locally-scoped) "notification" statements.

5. Provide a set of documents enabling advanced notification/subscription
capabilities, which gracefully co-exist with deployments of NETCONF Event
Notification (RFC 5277). The new capabilities include transport independence
and multiple dynamic and configured subscriptions in a single transport
session. RFC 5277 will be obsoleted in parallel with the publication of the
new document set. The following specifications will be published: - A
protocol-independent notification framework, 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 and considerations for parallel
support and implementation compatibility with RFC 5277 will be included. -
Definition of notifications sent over RESTCONF and HTTP2 and of how YANG
notifications are encoded in XML and JSON, including 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. - Definition of transport agnostic notification headers and
of a mechanism for bundling multiple YANG notifications into a single message.

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

7. Coordinate with I2RS to support the I2RS profile use of RESTCONF and,
optionally, NETCONF, and the I2RS dynamic datastore(s).

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 NETCONF Protocol (RFC6241) and NETCONF over
SSH (RFC6242) and addressing any reported errata.

Milestones:
 Jun 2017 - WGLC for RFC 6536bis (NETCONF Access Control Model)
 Jul 2017 - Submit RFC 6536bis to AD/IESG for consideration as Proposed
Standard 
 Jul 2017 - WGLC for Zero-touch Configuration Mechanism 
 Jul 2017 - WGLC for System-level Keystore Mechanism 
 Jul 2017 - WGLC for Server and Client Configuration Models for NETCONF 
and RESTCONF
 Jul 2017 - WGLC for Client and Server Configuration Models for SSH and 
TLS 
 Jul 2017 - WGLC for advanced Notification/Subscription Specifications 
 Aug 2017 - Submit Zero-touch Configuration Mechanism to AD/IESG for 
consideration as Proposed Standard
 Aug 2017 - Submit System-level Keystore Mechanism to AD/IESG for 
consideration as Proposed Standard
 Aug 2017 - Submit Server and Client Configuration Models for NETCONF 
and RESTCONF to AD/IESG for consideration as Proposed Standard
 Aug 2017 - Submit Client and Server Models Configuration Models for SSH 
and TLS to AD/IESG for consideration as Proposed Standard
 Aug 2017 - Submit Notification/Subscription Specifications to AD/IESG 
for consideration as Proposed Standard
 Nov 2017 - WGLC for NETCONF and RESTCONF bis protocols
 Dec 2017 - Submit NETCONF and RESTCONF bis protocols to AD/IESG for 
consideration as Proposed Standard