Re: [Netconf] Draft Charter Proposal for NETCONF WG

[Ladislav Lhotka <[e-mail]>]

"t.petch" <[e-mail]> writes:

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

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.

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

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.

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

I agree.

Lada


>
> 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
>>
>
> _______________________________________________
> Netconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf

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