Re: [Netconf] Draft Charter Proposal for NETCONF WG

True. Timing is important.
We might go for a 7950bis first or publish 7950bis and 6241bis at the same
time with consistent content.

Mehmet

> -----Original Message-----
> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
> Sent: Tuesday, February 28, 2017 2:38 PM
> To: t.petch <ietfc@btconnect.com>; Mehmet Ersue <mersue@gmail.com>;
> 'Netconf' <netconf@ietf.org>; 'Benoit Claise' <bclaise@cisco.com>
> Subject: Re: [Netconf] Draft Charter Proposal for NETCONF WG
> 
> "t.petch" <ietfc@btconnect.com> 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" <mersue@gmail.com>
> > To: "'Netconf'" <netconf@ietf.org>; "'Benoit Claise'"
> > <bclaise@cisco.com>
> > 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
> >> Netconf@ietf.org
> >> https://www.ietf.org/mailman/listinfo/netconf
> >>
> >
> > _______________________________________________
> > Netconf mailing list
> > Netconf@ietf.org
> > https://www.ietf.org/mailman/listinfo/netconf
> 
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67