Re: [Netconf] Draft Charter Proposal for NETCONF WG

["Mehmet Ersue" <[e-mail]>]

Dear All,

 

based on the recent discussion and proposals please find below the updated
charter proposal for NETCONF WG.

Please comment before March 24, 2017.

 

Following Benoit's support the I2RS-related additions have been added as a
separated item.

Being dependent on netmod-revised-datastores point 6 and 7 have been defined
as a goal without a deadline.

 

Mehmet

 

Network Configuration (netconf)

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

 

Charter

 

Current Status: Active

 

Chairs:

     Mahesh Jethanandani <[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:          <https://mailarchive.ietf.org/arch/browse/netconf/>
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). 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 

  workgroup will focus on following items:

 

  1. Finalize the YANG data module for a system-level keystore mechanism,

  that 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 how YANG 

     notifications are encoded in XML and JSON. Include considerations 

     for parallel support / implementation compatibility with RFC-5277.

   - 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. 

 

  6. Provide a revision for the NETCONF and RESTCONF protocols and the

  used datastore framework building on the datastore concept in NETMOD 

  revised datastores work. Bug fixing will be done and potential   

  extensions will be added. Provide guidance on how to adapt and use 

  YANG with NETCONF and RESCONF protocols. NETCONF XML Encoding Rules 

  from RFC 7950 will be moved to RFC6241bis.

 

  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 errata.

 

 

Goals and Milestones:

  Done     Submit NETCONF/RESTCONF Call Home to AD/IESG for consideration as
Proposed Standard

  Done     Submit YANG Library to AD/IESG for consideration as Proposed
Standard

  Done     Submit RESTCONF to AD/IESG for consideration as Proposed Standard

  Done     Submit YANG Patch to AD/IESG for consideration as Proposed
Standard

 

  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 Standard 

  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

 

 

From: Benoit Claise [mailto:[e-mail]] 
Sent: Friday, March 17, 2017 4:49 PM
To: Kent Watsen <[e-mail]>; Mehmet Ersue <[e-mail]>;
'Susan Hares' <[e-mail]>; 'Andy Bierman' <[e-mail]>
Cc: 'Netconf' <[e-mail]>
Subject: Re: [Netconf] Draft Charter Proposal for NETCONF WG

 

On 3/8/2017 12:57 AM, Kent Watsen wrote:

I agree with Mehmet, any changes to the NC/RC protocols should be done in
the NETCONF WG.

+1.

Regards, Benoit



 

K.

 

 

On 3/7/17, 3:15 PM, "Netconf on behalf of Mehmet Ersue"
<[e-mail] <mailto:[e-mail]>  on behalf of
[e-mail] <mailto:[e-mail]> > wrote:

 

Hi Sue,

 

I personally prefer to publish such NC/RC add-ons in NETCONF WG as they
belong together.

I would like to suggest to discuss on the maillist and let NETCONF WG decide
in Chicago.

 

BR,

Mehmet

 

From: Susan Hares [mailto:[e-mail]] 
Sent: Tuesday, March 7, 2017 7:36 PM
To: 'Mehmet Ersue'  <mailto:[e-mail]> <[e-mail]>; 'Andy
Bierman'  <mailto:[e-mail]> <[e-mail]>
Cc: 'Juergen Schoenwaelder'  <mailto:[e-mail]>
<[e-mail]>; 't.petch'
<mailto:[e-mail]> <[e-mail]>; 'Netconf'
<mailto:[e-mail]> <[e-mail]>
Subject: RE: [Netconf] Draft Charter Proposal for NETCONF WG

 

Mehmet:

 

Sounds like a good plan to do the RESTCONF additions for I2RS in I2RS.  

How do we make this official?   Should we do the same for NETCONF additions
for I2RS?  

 

Sue 

 

From: Mehmet Ersue [mailto:[e-mail]] 
Sent: Tuesday, March 7, 2017 12:34 PM
To: 'Susan Hares'; 'Andy Bierman'
Cc: 'Juergen Schoenwaelder'; 't.petch'; 'Netconf'
Subject: RE: [Netconf] Draft Charter Proposal for NETCONF WG

 

Hi Sue,

 

providing add-ons which don't require republishing of RESTCONF-8040 would be
indeed important.

 

I don't mind if add-ons to RESTCONF specific to I2RS are done in I2RS.

However forcing serious reviews early and publishing them in NETCONF would
be my preference. 

In any case we need I2RS people working on it.

 

BR,

Mehmet

 

From: Susan Hares [mailto:[e-mail]] 
Sent: Tuesday, March 7, 2017 5:27 PM
To: 'Andy Bierman' <[e-mail] <mailto:[e-mail]> >
Cc: 'Mehmet Ersue' <[e-mail] <mailto:[e-mail]> >; 'Juergen
Schoenwaelder' <[e-mail]
<mailto:[e-mail]> >; 't.petch'
<[e-mail] <mailto:[e-mail]> >; 'Netconf'
<[e-mail] <mailto:[e-mail]> >
Subject: RE: [Netconf] Draft Charter Proposal for NETCONF WG

 

Andy: 

 

Thank you for the clarification.  Since this is an Add-on and not focused on
the base specification, where should the Add-on specification be worked on?
I2RS WG with final cross-review in NETCONF?   It seems that NETCONF has lots
of other work on the list.  

 

Sue 

 

From: Andy Bierman [mailto:[e-mail]] 
Sent: Tuesday, March 7, 2017 11:25 AM
To: Susan Hares
Cc: Mehmet Ersue; Juergen Schoenwaelder; t.petch; Netconf
Subject: Re: [Netconf] Draft Charter Proposal for NETCONF WG

 

 

 

On Tue, Mar 7, 2017 at 7:01 AM, Susan Hares <[e-mail]
<mailto:[e-mail]> > wrote:

Mehmet:

These are clarifying question - not requests.

Do the items #6 and #7 on the charter include revising the NETCONF and
RESTCONF to serve as a control plane protocol that interacts with the I2RS
control plane data store supporting the ephemeral datastore?   If so, based
on the WGs comments it seems key players (Andy Bierman for RESTCONF and a
group of players for NETCONF) do not want this work to be done in the
NETCONF WG.   Do I understand the sense of the mail list?

 

My position is that I2RS features can be done in its own RFC without

republishing the RESTCONF RFC.  Since this functionality is

optional-to-implement, a new protocol version is not required.

 

 

 

Sue Hares

 

Andy

 


-----Original Message-----
From: Netconf [mailto:[e-mail]
<mailto:[e-mail]> ] On Behalf Of Mehmet Ersue
Sent: Friday, March 3, 2017 9:34 AM
To: 'Juergen Schoenwaelder'; 't.petch'
Cc: 'Netconf'
Subject: Re: [Netconf] Draft Charter Proposal for NETCONF WG

> Back to your question, it seems obvious to me that YANG and the XML
encoding rules naturally belong to NETMOD, the 'NETCONF protocol details
that NETCONF
> did not define' naturally belong to NETCONF.

Basically it is our aim to make the YANG language specification generally
applicable to all protocols and to put protocol-specific details into the
protocol specifications.

Mehmet

> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-
<mailto:j.schoenwaelder@jacobs-> 
> university.de <http://university.de> ]
> Sent: Friday, March 3, 2017 2:35 PM
> To: t.petch <[e-mail] <mailto:[e-mail]> >
> Cc: Kent Watsen <[e-mail] <mailto:[e-mail]> >;
Mehmet Ersue
> <[e-mail] <mailto:[e-mail]> >; 'Netconf' <[e-mail]
<mailto:[e-mail]> >; 'Benoit Claise'
> <[e-mail] <mailto:[e-mail]> >
> Subject: Re: [Netconf] Draft Charter Proposal for NETCONF WG
>
> On Fri, Mar 03, 2017 at 12:24:34PM +0000, t.petch wrote:
> > ----- Original Message -----
> > From: "Kent Watsen" <[e-mail] <mailto:[e-mail]> >
> > Sent: Wednesday, March 01, 2017 8:14 PM
> >
> > > > Kent
> > > >
> > > > 7 is a monster because of the XML encoding rules, not because of
> > > > the revised datastore concepts.  And datastores, as you say, are
> > > > more important - revising the XML encoding rules is cosmetic,
> > > > not needed technically and, as I said, only make sense when the
> > > > NETMOD WG has
> > done
> > > > its bit; and the revised charter being discussed on the NETMOD
> > > > list makes no mention of this work.
> > > >
> > > > So scrap NETCONF XML encoding rules.
> > > >
> > > > Tom Petch
> > >
> > >
> > > Hi Tom,
> > >
> > > Such changes fall under the "maintaining" clauses in the NETMOD
> > charter:
> > >
> > >   a) Maintaining the data modeling language YANG.  This effort entails
> > >      periodically updating the specification to address new
> > requirements
> > >      as they arise.
> > >
> > >   d) Maintaining encodings for YANG modeled data.  This effort entails
> > >      updating encodings already defined by the NETMOD working group
> > >      (XML and JSON) to accommodate changes to the YANG specification,
> > >      and defining new encodings that are needed, and yet do not fall
> > >      under the charter of any other active IETF working group.
> >
> > Kent
> >
> > I was going to be sarcastic but resisted the temptation:-)
> >
> > I am unable to reconcile those paragraphs with
> >
> > 'NETCONF XML Encoding Rules from RFC 7950 will be moved to
> > RFC6241bis.'
> >
> > To me, they are on different planets; one puts XML encoding rules in
> > the NETCONF WG and the NETCONF RFC, the other places them in the
> > NETMOD WG and the NETMOD RFC.
> >
>
> YANG today defines the language plus its data encoding rules into XML
> plus NETCONF protocol details that NETCONF did not define (and the
> reason is simply that YANG was done after NETCONF and nothing else).
>
> I think the goal is to move the NETCONF protocol details that NETCONF
> did not define to the NETCONF specification. Some may want to factor
> out the XML encoding out of the YANG specification as well, similar to
> how we have JSON as a separate document. On the hand hand this makes
> sense, on the other hand it makes it a bit more difficult to write
> examples down in the YANG specification (since the examples then
> depend on another external specification - or one would have to create
> yet another ad-hoc notation (YAAN).
>
> Back to your question, it seems obvious to me that YANG and the XML
> encoding rules naturally belong to NETMOD, the 'NETCONF protocol
> details that NETCONF did not define' naturally belong to NETCONF.
>
> /js
>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   [phone]         <http://www.jacobs-university.de/>

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

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

 






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