Re: [Netconf] Netconf Charter update for approval

[Benoit Claise <[e-mail]>]

Dear all,

Sorry for the delay in getting back to you.

Today Bert, Mehmet, and I had a quick conf. call regarding the charter, 
and we made a few modifications.
You can follow up the temp charter text at 
http://datatracker.ietf.org/doc/charter-ietf-netconf/
Under the history tab, there is a very useful diff tool.
     The version 15, dated May 31st is the current official charter
     The version 15-06, dated Jan 10th, is the charter as proposed below 
in this email
     The version 15-11, dated today, is the charter after our discussion 
today.

As you can see from the diffs:
- we added the zero touch configuration document
- we tried to justify why the YANG patch document is needed
- we updated the milestones
- we added an important sentence regarding the RESTCONF/NETCONF alignment:
     RESTCONF should not deviate from NETCONF unless proper 
justifications is provided
     and documented.
- minor edits

Feedback?

I have two more points:

1. A question to which I've been receiving different answers from 
different persons: I understand that RESTCONF is an additional 
simplified interface that follows RESTful principles and is compatible 
with a resource-oriented device abstraction, but will RESTCONF be in 
line with the RFC 3535 section 3 requirements.
I understand that those requirements are for the communication between 
the NMS and the managed device. Hence my question during the last 
meeting opendaylight presentation: will RESTCONF be used as north bound 
interface only protocol, or also as a south bound interface. The answer 
was both: So we might have different (competing) solutions to managed 
devices.

2. HTTP2.0 is developed in the HTTPbis WG.
I see that draft-bierman-netconf-restconf is based on HTTP 1.1. Will it 
still work with HTTP2.0? Or is this completely orthogonal?
I've not been been following the HTTP2.0 developments, so I don't even 
know if this is a valid question, but I'm wondering if we should say 
something about the HTTP 2.0 compatibility in the charter?

Regards, Benoit
> Dear Benoit,
> hope you had restful holidays.
> Below is the charter proposal we prepared following the consensus 
> calls and review of the draft charter text, basically adding to the WG 
> item list point 3. for the joint server configuration data model and 
> point 4. for RESTCONF.
> We would like to ask you to initiate the re-chartering and the 
> approval by the IESG. Thank you.
> Bert & Mehmet
> ---------------
> Network Configuration (netconf)
> -------------------------------
> Charter
> Current Status: Active
> Chairs:
>      Bert Wijnen <[e-mail]>
>      Mehmet Ersue <[e-mail]>
> Operations and Management Area Directors:
>      Benoit Claise <[e-mail]>
>      Joel Jaeggli <[e-mail]>
> Operations and Management Area Advisor:
>      Benoit Claise <[e-mail]>
> Mailing Lists:
>      General Discussion: [e-mail]
>      To Subscribe: 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 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. 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.
>   3. Combine the server configuration data models from Reverse SSH and
>   RFC5539bis drafts in a separate YANG module.
>   4. Develop a RESTful interface (RESTCONF) for accessing YANG data using
>   the datastores defined in NETCONF. The YANG patch operation will be 
> prepared
>   in a separate draft.
> Goals and Milestones:
>   Jan 2014 - Submit initial WG drafts for RESTCONF as WG item
>   Apr 2014 - WGLC for RFC5539bis
>   Apr 2014 - WGLC for Reverse SSH
>   Apr 2014 - WGLC for NETCONF server configuration data model
>   May 2014 - Submit Reverse SSH to AD/IESG for consideration as 
> Proposed Standard
>   May 2014 - Submit RFC5539bis to AD/IESG for consideration as 
> Proposed Standard
>   Jun 2014 - WGLC for RESTCONF drafts
>   Aug 2014 - Submit RESTCONF to AD/IESG for consideration as Proposed 
> Standard