Subject: [Netconf] Draft Charter Proposal for NETCONF WG

From: "Mehmet Ersue" <[email-masked]>
Date: Mon, 27 Feb 2017 21:44:06 +0100

Dear NETCONF WG,

please find below the draft charter proposal the co-chairs have prepared for
your review.

Please send your comments to NETCONF maillist by March 10, 2017.

Thanks,

Mehmet & Mahesh

Draft Charter for NETCONF WG

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 concepts
defined in the NETCONF protocol specification. In support of RESTCONF the
YANG-Patch (RFC XXYY) 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 (RFC XXYY) and RESTCONF Call Home (RFC XXYY) 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. Revise the current NETCONF datastore concept as a protocol- and modeling
language-independent standard as part of the network configuration
framework. Use the datastore solution proposal in
draft-ietf-netmod-revised-datastores as its basis. Will be used as a
normative reference in protocol specifications.

7. Provide a revision for the NETCONF and RESTCONF protocols building on the
revised NETCONF datastore concept. 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.

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 RFCs and addressing any
reported errata.

Milestones 

Mar 2017         WGLC for Zero-touch configuration mechanism

Apr 2017         Submit Zero-touch configuration to AD/IESG for
consideration as Proposed Standard 

May 2017        WGLC for system-level keystore mechanism

June 2017        Submit keystore mechanism to AD/IESG for consideration as
Proposed Standard 

May 2017        WGLC for Server and Client models for NETCONF and RESTCONF

June 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

June 2017        Submit Client and Server Models for SSH and TLS to AD/IESG
for consideration as Proposed Standard 

June 2017        WGLC for RFC 6536bis (NETCONF Access Control Model) 

July 2017         Submit RFC 6536bis to AD/IESG for consideration as
Proposed Standard

June 2017        WGLC for advanced Notification/Subscription specifications 

July 2017         Submit Notification/Subscription specifications to AD/IESG
for consideration as Proposed Standard

Aug 2017         WGLC for generic NETCONF datastore concept 

Aug 2017         Submit NETCONF datastore concept to AD/IESG for
consideration as Proposed Standard

Sep 2017          WGLC for NETCONF and RESTCONF bis documents

Oct 2017          Submit to NETCONF and RESTCONF bis documents AD/IESG for
consideration as Proposed Standard

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 27 Feb 2017 23:14:34 +0100

> normative reference in protocol specifications.

There is no point in dupliating work in WGs that have a common history
and a common set of active contributors.

/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: Lou Berger <[email-masked]>
Date: Mon, 27 Feb 2017 17:21:43 -0500

> and a common set of active contributors.

I read 6 as covering any protocol specific implications of revised data
stores, in which case it's (more) reasonable for this
discussion/work/docs to be in NetConf.

Lou

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 27 Feb 2017 23:24:25 +0100

> discussion/work/docs to be in NetConf.

This is not my reading of this text. Obviously, the text needs
clarification to make the intention clear.

/js

---

From: Lou Berger <[email-masked]>
Date: Mon, 27 Feb 2017 18:03:27 -0500

> clarification to make the intention clear.

Fair enough -- I do agree that it work should not be duplicated across WGs.

Lou

---

From: t.petch <[email-masked]>
Date: Tue, 28 Feb 2017 12:02:49 +0000

7 is the monster, likely to take years rather than months and I think
likely to create confusion, perhaps chaos.

I think the rational approach would be to create 7950bis first, removing
the NETCONF material into a separate I-D alongside 7950bis, and then
merging that into 6241bis if it still seems sensible.  Taking the 60+
bits and pieces out of 7950 is not too bad, what is left still makes
sense.

Creating a 6241bis that overlaps masses of bits and pieces of 7950 -
well, chaos is my expectation.  What use is an XML Example without the
YANG that it is an example of and what sense does that YANG snippet make
in isolation?  Just how much do we put into 6241bis?

Even updating 7950 I would expect to be resisted given how long it took
to appear but for me, it is the only logical first step and not that
difficult one, just tedious to proof-read.

Tom Petch

----- Original Message -----
From: "Mehmet Ersue" <[email-masked]>
To: "'Netconf'" <[email-masked]>; "'Benoit Claise'"
<[email-masked]>
Sent: Monday, February 27, 2017 8:44 PM

> consideration as Proposed Standard

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

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

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 28 Feb 2017 14:37:36 +0100

> bits and pieces out of 7950 is not too bad, what is left still makes

Right, we need to think hard about a sensible separation of
concerns and remove, as much as possible, circular dependencies of
NETCONF and NETMOD documents.

> in isolation?  Just how much do we put into 6241bis?

Yes, I believe there is now no point to pretend that NETCONF is independent
of YANG. In fact, some NETCONF operations are ill-defined without the
additional YANG semantics such as list keys.

> difficult one, just tedious to proof-read.

I agree.

Lada

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

---

From: Andy Bierman <[email-masked]>
Date: Tue, 28 Feb 2017 09:01:59 -0800

> ....

I am opposed to creating new versions of NETCONF or RESTCONF at this time.
I do not see anything in the charter that cannot be defined in RFCs that
update (not obsolete)
the existing protocols.  Both are designed to allow new functionality to be
added and advertised as capabilities.

Andy

---

From: Kent Watsen <[email-masked]>
Date: Tue, 28 Feb 2017 20:51:19 +0000

>> difficult one, just tedious to proof-read.

As a NETMOD co-chair, I plan to start a preliminary 7950bis discussion in Chicago.  The scope of such an effort would be the key topic, but hopefully factoring out all the NETCONF and XML specific parts would be near the top of the list.  I know some think that we should not waste resources on housekeeping, but I believe that periodic cleanups are necessary to keep things running smoothly...

Of course, the XML-specific parts factored out of RFC7950 would go into another NETMOD WG draft (mirroring RFC 7951) and the NETMOD WG could ensure to run both the 7950bis and draft-ietf-netmod-yang-xml drafts at the same time (for as clean a cutover as possible).  However, it would be up to the NETCONF WG to pick-up the NETCONF-specific parts factored out of RFC7950, and it would be up to the NETCONF WG to decide to do this work now, or wait to do it in parallel with the NETMOD WG (whenever that might be), or wait until after 7950bis comes out.

While it seems like the NETCONF WG could kick-off this activity now if it wanted to, said activity is nowhere near as important as updating NETCONF WG maintained documents to support the solution defined in the revised-datastores draft (namely RFCs 6241, 7895, 8040).  Without said update, there would be no way for clients to access ephemeral configuration (i2rs requirement) or operational state (open config requirement).  So, this is clearly a higher priority, though it seems that the two could be done at the same time, as is captured by work item #7 in Mehmet's charter proposal.

So, my opinion is that Mehmet's proposal is nearly spot-on with its work item #7.  Yes, it’s a "monster", but it must be done ASAP or else we fail to deliver the datastore solution in a timely manner.  The only thing I hesitate on is that I don't think the WG has enough information to decide if it's better to work on new standalone drafts or -bis of existing drafts (this addresses Andy's point).  To the extent the charter describes changes being made to specific documents, it may be better to remove this part from the charter until more information is known.

PS: the next update to the revised datastores draft will contain an Appendix section for each RFC believed to be impacted, in both the NETMOD and NETCONF WGs, along with a proposal for how that RFC might be changed or updated.  The revised datastore authors plan to request a NETCONF WG presentation timeslot to go over the impact to NETCONF WG drafts, with the intent of asking the WG how to proceed (e.g., standalone NETCONF WG drafts or -bis on existing drafts).  So, we'll be having this discussion then, can the charter wait that long?

Kent

---

From: Andy Bierman <[email-masked]>
Date: Tue, 28 Feb 2017 17:44:36 -0800

On Tue, Feb 28, 2017 at 9:01 AM, Andy Bierman <[email-masked]> wrote:

>> Oct 2017          Submit to NETCONF and RESTCONF bis documents AD/IESG
I should clarify this comment.
NETCONF was last published in June 2011 so it is not unreasonable to
do a new version.  But all protocol features should be on the table.
There is a list (in case you have an important feature to add to the list)

https://github.com/netconf-wg/rfc6241bis/issues

If the scope is just support for revised datastores, then than can go in
its own RFC.
If the scope is applying the lessons we have learned since June 2011 to make
NETCONF much better, then 6241bis is appropriate.

RESTCONF was published a month ago so a new version should not be in scope.

Andy

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 1 Mar 2017 03:03:30 +0000

Hi Kent,
Hi Lou,

> 
> As a NETMOD co-chair, I plan to start a preliminary 7950bis discussion in
> Chicago.  The scope of such an effort would be the key topic, but hopefully
> factoring out all the NETCONF and XML specific parts would be near the top of
> the list.  I know some think that we should not waste resources on
> housekeeping, but I believe that periodic cleanups are necessary to keep things
> running smoothly...
> 
> Of course, the XML-specific parts factored out of RFC7950 would go into
> another NETMOD WG draft (mirroring RFC 7951) and the NETMOD WG could
> ensure to run both the 7950bis and draft-ietf-netmod-yang-xml drafts at the
> same time (for as clean a cutover as possible).  However, it would be up to the
> NETCONF WG to pick-up the NETCONF-specific parts factored out of RFC7950,
> and it would be up to the NETCONF WG to decide to do this work now, or wait
> to do it in parallel with the NETMOD WG (whenever that might be), or wait
> until after 7950bis comes out.
> 
> While it seems like the NETCONF WG could kick-off this activity now if it
> wanted to, said activity is nowhere near as important as updating NETCONF
> WG maintained documents to support the solution defined in the revised-
> datastores draft (namely RFCs 6241, 7895, 8040).  Without said update, there
> would be no way for clients to access ephemeral configuration (i2rs
> requirement) or operational state (open config requirement).  So, this is clearly
> a higher priority, though it seems that the two could be done at the same time,
> as is captured by work item #7 in Mehmet's charter proposal.
> 
> So, my opinion is that Mehmet's proposal is nearly spot-on with its work item
> #7.  Yes, it’s a "monster", but it must be done ASAP or else we fail to deliver the
> datastore solution in a timely manner.  The only thing I hesitate on is that I
> don't think the WG has enough information to decide if it's better to work on
> new standalone drafts or -bis of existing drafts (this addresses Andy's point).
> To the extent the charter describes changes being made to specific documents,
> it may be better to remove this part from the charter until more information is
> known.
> 
> PS: the next update to the revised datastores draft will contain an Appendix
> section for each RFC believed to be impacted, in both the NETMOD and
> NETCONF WGs, along with a proposal for how that RFC might be changed or
> updated.  The revised datastore authors plan to request a NETCONF WG
> presentation timeslot to go over the impact to NETCONF WG drafts, with the
> intent of asking the WG how to proceed (e.g., standalone NETCONF WG drafts
> or -bis on existing drafts).  So, we'll be having this discussion then, can the
> charter wait that long?

The datastore Mount work of draft-clemm-netmod-mount-05 is not protocol specific.  I can see usefulness if used in conjunction with the revised datastore work continues as it could provide remote referencing mechanisms for these datastores.

Do you see such datastore access mechanisms worthy of discussing for NETMOD scope in Chicago?

Eric