Subject: [Netconf] Draft charter update for review

From: "Ersue, Mehmet (Nokia - DE/Munich)" <[email-masked]>
Date: Thu, 17 Sep 2015 22:25:22 +0000

Dear NETCONF WG,

please find below the draft charter update which we provided to our AD for review.
Comments are welcome.

Mehmet & Mahesh

------------------

Network Configuration (netconf)
-------------------------------

Charter

Current Status: Active

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

Operations and Management Area Directors:
     Benoit Claise <[email-masked]<mailto:[email-masked]>>
     Joel Jaeggli <[email-masked]<mailto:[email-masked]>>

Operations and Management Area Advisor:
     Benoit Claise <[email-masked]<mailto:[email-masked]>>

Mailing Lists:
     General Discussion: [email-masked]<mailto:[email-masked]>
     To Subscribe:       https://www.ietf.org/mailman/listinfo/netconf
     Archive:            https://mailarchive.ietf.org/arch/browse/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 (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) and uses an XML-based data representation. The NETCONF protocol
  is data modeling language independent, but YANG (RFC 6020) is the recommended
  NETCONF modeling language, which introduces advanced
  language features for configuration management.

  Recently NETCONF WG define the Call Home mechanism for NETCONF and RESTCONF protocols
  as well as updated RFC5539 by adding the new message framing used by NETCONF 1.1.

  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. Combine the server configuration data models from the Call Home and RFC5539bis drafts in a separate Server Configuration YANG module by addressing the need for NETCONF as well as RESTCONF.

  2. Develop RESTCONF, a protocol based on NETCONF in terms of capabilities, but over HTTP and with some REST characteristics, for accessing YANG data in NETCONF datastores. 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.
In addition develop a YANG library, which identifies the information about all YANG modules used by a server. Furthermore develop a collection resource for the RESTCONF protocol to provide enhanced filtering features for the retrieval of data nodes with the GET method.
RESTCONF should not deviate from the NETCONF capabilities unless proper justification is provided and documented. The RESTCONF work will consider requirements suggested by the other working groups (for example I2RS).

    3. Develop a zero touch configuration document (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), specific to the NETCONF use case.

    4. Develop a subscription and push mechanism that allows client applications to request notifications for changes in the datastore. These updates will be pushed by the server to the client based on a subscription policy.

    5. Update RFC 6536 (NETCONF Access Control Model) to introduce access control rights associated with actions.

    6.Enhance RFC 5277 with the ability to delete subscriptions without closing the client session, to modify existing subscriptions, and to have multiple subscriptions on a established client session. These changes should not affect older clients that do not support these particular subscription requirements. The RPCs and the data models in RFC 5277 should be converted to YANG.

Goals and Milestones:

  Done - Submit RFC5539bis to AD/IESG for consideration as Proposed Standard
  Done - Submit NETCONF call home mechanism to AD/IESG for consideration as Proposed Standard

  Oct 2015 - WGLC for RESTCONF, YANG patch operation and YANG Library drafts
  Nov 2015 - Submit RESTCONF to AD/IESG for consideration as Proposed Standard

  Jan 2016 - WGLC for RFC5277bis draft
  Jan 2016 - Submit RFC5277bis to AD/IESG for consideration as Proposed Standard
  Jan 2016 - WGLC for YANG datastore push update draft
  Feb 2016 - Submit YANG datastore push update to AD/IESG for consideration as Proposed Standard

  Feb 2016 - WGLC for RFC6536bis draft
  Feb 2016 - Submit RFC6536bis to AD/IESG for consideration as Proposed Standard

  Feb 2016 - WGLC for zero touch configuration
  Feb 2016 - WGLC for RESTCONF Collection Resource draft
  Mar 2016 - Submit zero touch configuration to AD/IESG for consideration as Proposed Standard
  Mar 2016 - Submit RESTCONF Collection to AD/IESG for consideration as Proposed Standard

  Mar 2016 - WGLC for NETCONF server configuration data model
  Apr 2016 - Submit server configuration data model to AD/IESG for consideration as

---

From: "Liubing (Leo)" <[email-masked]>
Date: Fri, 18 Sep 2015 06:40:45 +0000

Hi Dear Chairs and all,

May I take the liberty of proposing another item that the WG might consider to include in the updated charter:

7. Develop a mechanism that allows multiple <rpc-reply> messages be associated together against one specific <rpc-request> message. This is a common requirement derived from several use cases such as buck replies, persistent replies .etc.

There is a draft-liu-netconf-multiple-replies discussing this issue. It had been presented in Netconf meeting a couple of times. And there was some supportive feedback during the presentations and mailing list discussion.

Your comments are welcomed! Thanks a lot.

Best regards,
Bing

From: Netconf [mailto:[email-masked]] On Behalf Of Ersue, Mehmet (Nokia - DE/Munich)
Sent: Friday, September 18, 2015 6:25 AM
To: Netconf
Subject: [Netconf] Draft charter update for review

Dear NETCONF WG,

Mehmet & Mahesh

------------------

Charter

Current Status: Active

Chairs:

Mailing Lists:

Goals and Milestones:

---

From: "Ersue, Mehmet (Nokia - DE/Munich)" <[email-masked]>
Date: Fri, 18 Sep 2015 12:46:34 +0000

Dear Bing,

the draft charter update, which is in AD review includes only topics which have been agreed and are known to the WG.

draft-clemm-netconf-yang-push has been approved to include as WG item in IETF #93.
There is no such WG agreement on draft-liu-netconf-multiple-replies available yet.

Mehmet

From: EXT Liubing (Leo) [mailto:[email-masked]]
Sent: Friday, September 18, 2015 8:41 AM
To: Ersue, Mehmet (Nokia - DE/Munich); Netconf
Cc: [email-masked]; Yangang; [email-masked]'
Subject: Proposing a new work in the charter-//RE: Draft charter update for review

Hi Dear Chairs and all,

Best regards,
Bing

Dear NETCONF WG,

Mehmet & Mahesh

------------------

Charter

Current Status: Active

Chairs:

Mailing Lists:

Goals and Milestones:

---

From: "Liubing (Leo)" <[email-masked]>
Date: Fri, 18 Sep 2015 13:22:51 +0000

Hi Dear Mehmet,

Maybe it's a bit abrupt to have the proposal at this point, sorry about that.
I missed last Netconf session due to conflict of another WG which I had to go. But I do hope to hear WG's opinions on this work. Does it make sense? Should we continue work on it?

Thanks a lot.

Best regards,
Bing

From: Ersue, Mehmet (Nokia - DE/Munich) [mailto:[email-masked]]
Sent: Friday, September 18, 2015 8:47 PM
To: Liubing (Leo); Netconf
Cc: [email-masked]; Yangang; [email-masked]'
Subject: RE: Proposing a new work in the charter-//RE: Draft charter update for review

Dear Bing,

Mehmet

Cc: [email-masked]<mailto:[email-masked]>; Yangang; [email-masked]'

Hi Dear Chairs and all,

Best regards,
Bing

Dear NETCONF WG,

Mehmet & Mahesh

------------------

Charter

Current Status: Active

Chairs:

Mailing Lists:

Goals and Milestones:

---

From: "Ersue, Mehmet (Nokia - DE/Munich)" <[email-masked]>
Date: Fri, 18 Sep 2015 14:18:10 +0000

All,

please comment on draft-liu-netconf-multiple-replies.

Mehmet

Sent: Friday, September 18, 2015 3:23 PM

Hi Dear Mehmet,

Thanks a lot.

Best regards,
Bing

Dear Bing,

Mehmet

Hi Dear Chairs and all,

Best regards,
Bing

Dear NETCONF WG,

Mehmet & Mahesh

------------------

Charter

Current Status: Active

Chairs:

Mailing Lists:

Goals and Milestones:

---

From: Rodney Cummings <[email-masked]>
Date: Wed, 23 Sep 2015 10:56:49 -0500

Hello,

I apologize for commenting a bit late on the proposed charter, but I have 
a concern.

The proposal states:
> RESTCONF should not deviate from the NETCONF capabilities unless proper 
justification 
> is provided and documented.

RESTCONF is currently being explored for use in many applications due to 
the fact that it is a subset of NETCONF capabilities, with a simpler 
implementation in servers. This is described in section 1.1 of the current 
draft (i.e. "Simple Subset of NETCONF Functionality").

In my opinion this is a benefit of RESTCONF that cannot be lost. If 
anything, the opposite strategy should be taken, in that NETCONF 
capabilities should only be added to RESTCONF with a strong justification.

Rodney

From:   "Ersue, Mehmet (Nokia - DE/Munich)" <[email-masked]>
To:     Netconf <[email-masked]>, 
Date:   09/17/2015 05:25 PM
Subject:        [Netconf] Draft charter update for review
Sent by:        "Netconf" <[email-masked]>

Dear NETCONF WG,
 
please find below the draft charter update which we provided to our AD for 
review.
Comments are welcome.
 
Mehmet & Mahesh
 
------------------ 

Charter
 
Current Status: Active
 
Chairs:
    Mahesh Jethanandani <[email-masked]>
    Mehmet Ersue <[email-masked]>
 
Operations and Management Area Directors:
     Benoit Claise <[email-masked]>
     Joel Jaeggli <[email-masked]>
 
Operations and Management Area Advisor:
     Benoit Claise <[email-masked]>
 
Mailing Lists:
     General Discussion: [email-masked]
     To Subscribe:       https://www.ietf.org/mailman/listinfo/netconf
     Archive:            https://mailarchive.ietf.org/arch/browse/netconf/

  The NETCONF protocol (RFC 6241) provides mechanisms to install, 
manipulate, 
  and delete the configuration of network devices. NETCONF is based on the 

  transport) and uses an XML-based data representation. The NETCONF 
protocol 
  is data modeling language independent, but YANG (RFC 6020) is the 
recommended 
  NETCONF modeling language, which introduces advanced
  language features for configuration management.
 
  Recently NETCONF WG define the Call Home mechanism for NETCONF and 
RESTCONF protocols 
  as well as updated RFC5539 by adding the new message framing used by 
NETCONF 1.1.
 
  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.

  1. Combine the server configuration data models from the Call Home and 
RFC5539bis drafts in a separate Server Configuration YANG module by 
addressing the need for NETCONF as well as RESTCONF.
 
  2. Develop RESTCONF, a protocol based on NETCONF in terms of 
capabilities, but over HTTP and with some REST characteristics, for 
accessing YANG data in NETCONF datastores. 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. 
In addition develop a YANG library, which identifies the information about 
all YANG modules used by a server. Furthermore develop a collection 
resource for the RESTCONF protocol to provide enhanced filtering features 
for the retrieval of data nodes with the GET method.
RESTCONF should not deviate from the NETCONF capabilities unless proper 
justification is provided and documented. The RESTCONF work will consider 
requirements suggested by the other working groups (for example I2RS).
 
    3. Develop a zero touch configuration document (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), specific to the NETCONF use 
case.
 
    4. Develop a subscription and push mechanism that allows client 
applications to request notifications for changes in the datastore. These 
updates will be pushed by the server to the client based on a subscription 
policy.
 
    5. Update RFC 6536 (NETCONF Access Control Model) to introduce access 
control rights associated with actions.
 
    6.Enhance RFC 5277 with the ability to delete subscriptions without 
closing the client session, to modify existing subscriptions, and to have 
multiple subscriptions on a established client session. These changes 
should not affect older clients that do not support these particular 
subscription requirements. The RPCs and the data models in RFC 5277 should 
be converted to YANG.
 
Goals and Milestones:
 
  Done - Submit RFC5539bis to AD/IESG for consideration as Proposed 
Standard
  Done - Submit NETCONF call home mechanism to AD/IESG for consideration 
as Proposed Standard
 
  Oct 2015 - WGLC for RESTCONF, YANG patch operation and YANG Library 
drafts
  Nov 2015 - Submit RESTCONF to AD/IESG for consideration as Proposed 
Standard
 
  Jan 2016 - WGLC for RFC5277bis draft
  Jan 2016 - Submit RFC5277bis to AD/IESG for consideration as Proposed 
Standard
  Jan 2016 - WGLC for YANG datastore push update draft
  Feb 2016 - Submit YANG datastore push update to AD/IESG for 
consideration as Proposed Standard
 
  Feb 2016 - WGLC for RFC6536bis draft
  Feb 2016 - Submit RFC6536bis to AD/IESG for consideration as Proposed 
Standard
 
  Feb 2016 - WGLC for zero touch configuration
  Feb 2016 - WGLC for RESTCONF Collection Resource draft
  Mar 2016 - Submit zero touch configuration to AD/IESG for consideration 
as Proposed Standard
  Mar 2016 - Submit RESTCONF Collection to AD/IESG for consideration as 
Proposed Standard
 
  Mar 2016 - WGLC for NETCONF server configuration data model
  Apr 2016 - Submit server configuration data model to AD/IESG for 
consideration as
 
 _______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

---

From: Benoit Claise <[email-masked]>
Date: Wed, 30 Sep 2015 13:05:04 +0200

Hi Rodney,

The sentence you mention tells: NETCONF and RESTCONF may differ but only 
for a good and documented reason.
And I believe it does the job.

Regards, Benoit
> Hello,
>
> I apologize for commenting a bit late on the proposed charter, but I 
> have a concern.
>
> The proposal states:
> > RESTCONF should not deviate from the NETCONF capabilities unless 
> proper justification
> RESTCONF is currently being explored for use in many applications due 
> to the fact that it is a subset of NETCONF capabilities, with a 
> simpler implementation in servers. This is described in section 1.1 of 
> the current draft (i.e. "Simple Subset of NETCONF Functionality").
>
> ------------------------------------------------------------------------
>
>
>
> Dear NETCONF WG,
>
>     Mahesh Jethanandani <[email-masked] 
> <mailto:[email-masked]>>
>
>     Mehmet Ersue <[email-masked] 
> <mailto:[email-masked]>>
>
>      Benoit Claise <[email-masked] <mailto:[email-masked]>>
>
>      Joel Jaeggli <[email-masked] <mailto:[email-masked]>>
>
>      Benoit Claise <[email-masked] <mailto:[email-masked]>>
>
> Mailing Lists:
>
>      General Discussion: [email-masked] <mailto:[email-masked]>
>
>      To Subscribe: _https://www.ietf.org/mailman/listinfo/netconf_
>
>      Archive: _https://mailarchive.ietf.org/arch/browse/netconf/_
>
>   1. Combine the server configuration data models from the Call Home 
> and RFC5539bis drafts in a separate Server Configuration YANG module 
> by addressing the need for NETCONF as well as RESTCONF.
>
> accessing YANG data in NETCONF datastores. 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.
>
> In addition develop a YANG library, which identifies the information 
> about all YANG modules used by a server. Furthermore develop a 
> collection resource for the RESTCONF protocol to provide enhanced 
> filtering features for the retrieval of data nodes with the GET method.
>
> RESTCONF should not deviate from the NETCONF capabilities unless 
> proper justification is provided and documented. The RESTCONF work 
> will consider requirements suggested by the other working groups (for 
> example I2RS).
>
> settings, and the Network Management System), specific to the NETCONF 
> use case.
>
> applications to request notifications for changes in the datastore. 
> These updates will be pushed by the server to the client based on a 
> subscription policy.
>
>     5. Update RFC 6536 (NETCONF Access Control Model) to introduce 
> access control rights associated with actions.
>
>     6.Enhance RFC 5277 with the ability to delete subscriptions 
> without closing the client session, to modify existing subscriptions, 
> and to have multiple subscriptions on a established client session. 
> These changes should not affect older clients that do not support 
> these particular subscription requirements. The RPCs and the data 
> models in RFC 5277 should be converted to YANG.
>
> Goals and Milestones:
>

---

From: Rodney Cummings <[email-masked]>
Date: Wed, 30 Sep 2015 10:20:17 -0500

Hi Benoit,

I think we will need to agree to disagree on this issue.

To me, the sentence in the charter sounds like the sort of thinking that 
resulted in XML being mandated for RESTCONF. After all, if NETCONF 
mandates XML, one can argue that RESTCONF should not deviate. 

Did the working group provide a "proper justification" to remove the XML 
mandate from RESTCONF?

I don't know, because the phrase "proper justification" is subjective. 
Maybe we did, and maybe we didn't. Therefore, it seems likely that we will 
repeat this sort of debate. Someone will propose to mandate a feature from 
NETCONF that increases the RESTCONF implementation burden. We can have 
another lengthy debate and vote each time this happens, but I don't see 
that as a good use of everyone's time.

If the sentence was changed to 
        "RESTCONF should provide optional features that align with NETCONF 
capabilities, unless proper justification is provided and documented."
then I would have no concerns. Addition of optional features does not 
increase the implementation complexity, because a server an choose to 
ignore the optional features.

Rodney

From:   Benoit Claise <[email-masked]>
To:     Rodney Cummings <[email-masked]>, "Ersue, Mehmet (Nokia - 
DE/Munich)" <[email-masked]>, 
Cc:     Netconf <[email-masked]>
Date:   09/30/2015 06:05 AM
Subject:        Re: [Netconf] Draft charter update for review

Hi Rodney,

Regards, Benoit
Hello, 

justification 

Rodney 

Dear NETCONF WG, 

Mehmet & Mahesh 
  
------------------   

Charter 
  
Current Status: Active 
  
Chairs: 

  
Mailing Lists: 

  

  

  

  

  
Goals and Milestones:

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 30 Sep 2015 17:58:09 +0200

> ignore the optional features.

Being feature complete to NETCONF was never the goal of RESTCONF. In
fact, the RESTCONF document says this:

   An HTTP-based management protocol does not need to mirror the
   functionality of the NETCONF protocol, but it needs to be compatible
   with NETCONF.  A simplified transaction model is needed that allows
   basic CRUD operations on a hierarchy of conceptual resources.  This
   represents a limited subset of the transaction capabilities of the
   NETCONF protocol.

It also says this:

   The base RESTCONF protocol is intentionally simple to allow
   deployment for as many use cases as possible.  Additional
   functionality can be defined in external documents, outside the scope
   of this document.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "Ersue, Mehmet (Nokia - DE/Munich)" <[email-masked]>
Date: Wed, 30 Sep 2015 17:39:50 +0000

Rodney,

I believe it is not necessary to change the statement in the charter as it says exactly what the WG aimed to state:
NETCONF and RESTCONF may differ but only for a good and documented reason.

I think there was sufficient justification on the maillist why RESTCONF should use a more relaxed rule for the encoding allowing "Either XML or JSON as mandatory".

Mehmet

From: EXT Rodney Cummings [mailto:[email-masked]]
Sent: Wednesday, September 30, 2015 5:20 PM
To: Benoit Claise
Cc: Ersue, Mehmet (Nokia - DE/Munich); Netconf
Subject: Re: [Netconf] Draft charter update for review

Hi Benoit,

To me, the sentence in the charter sounds like the sort of thinking that resulted in XML being mandated for RESTCONF. After all, if NETCONF mandates XML, one can argue that RESTCONF should not deviate.

Did the working group provide a "proper justification" to remove the XML mandate from RESTCONF?

I don't know, because the phrase "proper justification" is subjective. Maybe we did, and maybe we didn't. Therefore, it seems likely that we will repeat this sort of debate. Someone will propose to mandate a feature from NETCONF that increases the RESTCONF implementation burden. We can have another lengthy debate and vote each time this happens, but I don't see that as a good use of everyone's time.

If the sentence was changed to
        "RESTCONF should provide optional features that align with NETCONF capabilities, unless proper justification is provided and documented."
then I would have no concerns. Addition of optional features does not increase the implementation complexity, because a server an choose to ignore the optional features.

Rodney

From:        Benoit Claise <[email-masked]<mailto:[email-masked]>>
To:        Rodney Cummings <[email-masked]<mailto:[email-masked]>>, "Ersue, Mehmet (Nokia - DE/Munich)" <[email-masked]<mailto:[email-masked]>>,
Cc:        Netconf <[email-masked]<mailto:[email-masked]>>
Date:        09/30/2015 06:05 AM
Subject:        Re: [Netconf] Draft charter update for review
________________________________

Hi Rodney,

The sentence you mention tells: NETCONF and RESTCONF may differ but only for a good and documented reason.
And I believe it does the job.

Regards, Benoit
Hello,

I apologize for commenting a bit late on the proposed charter, but I have a concern.

The proposal states:
> RESTCONF should not deviate from the NETCONF capabilities unless proper justification

RESTCONF is currently being explored for use in many applications due to the fact that it is a subset of NETCONF capabilities, with a simpler implementation in servers. This is described in section 1.1 of the current draft (i.e. "Simple Subset of NETCONF Functionality").

In my opinion this is a benefit of RESTCONF that cannot be lost. If anything, the opposite strategy should be taken, in that NETCONF capabilities should only be added to RESTCONF with a strong justification.

Rodney

From:        "Ersue, Mehmet (Nokia - DE/Munich)" <[email-masked]><mailto:[email-masked]>
To:        Netconf <[email-masked]><mailto:[email-masked]>,
Date:        09/17/2015 05:25 PM
Subject:        [Netconf] Draft charter update for review
Sent by:        "Netconf" <[email-masked]><mailto:[email-masked]>

________________________________

Dear NETCONF WG,

Comments are welcome.

Mehmet & Mahesh

------------------

Charter

Current Status: Active

Chairs:

Mailing Lists:

  any reported errata.

Goals and Milestones:

 _______________________________________________
Netconf mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netconf

_______________________________________________
Netconf mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netconf