Re: [Netconf] Draft Charter Proposal for NETCONF WG

[t.petch <[e-mail]>]

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" <[e-mail]>
To: "'Netconf'" <[e-mail]>; "'Benoit Claise'"
<[e-mail]>
Sent: Monday, February 27, 2017 8:44 PM

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


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


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