Re: [Netconf] Draft charter update for review

[Benoit Claise <[e-mail]>]

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
> > 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)" <[e-mail]>
> To: Netconf <[e-mail]>,
> Date: 09/17/2015 05:25 PM
> Subject: [Netconf] Draft charter update for review
> Sent by: "Netconf" <[e-mail]>
>
> ------------------------------------------------------------------------
>
>
>
> 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 <[e-mail]_ 
> <mailto:[e-mail]>>
>
>     Mehmet Ersue <[e-mail]_ 
> <mailto:[e-mail]>>
>
> Operations and Management Area Directors:
>
>      Benoit Claise <[e-mail]_ <mailto:[e-mail]>>
>
>      Joel Jaeggli <[e-mail]_ <mailto:[e-mail]>>
>
> Operations and Management Area Advisor:
>
>      Benoit Claise <[e-mail]_ <mailto:[e-mail]>>
>
> Mailing Lists:
>
>      General Discussion: [e-mail]_ <mailto:[e-mail]>
>
>      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
>
> _______________________________________________
> Netconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf
>
>
>
> _______________________________________________
> Netconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf