Re: [Netconf] Draft Charter Proposal for NETCONF WG

Tom,
If you read the two drafts and look at the data nodes in the two models,
you¹ll quickly realize that they have entirely different purposes.
Thanks,
Acee 

On 3/21/17, 7:21 AM, "rtgwg on behalf of Jeff Tantsura"
<rtgwg-bounces@ietf.org on behalf of jefftant.ietf@gmail.com> wrote:

>Tom,
>
>Including RTGWG, the draft-ietf-rtgwg-yang-key-chain home.
>In general, there¹s no interactions, rtgwg-yang-key-chain work has been
>focused on data model for routing protocols key-chain¹s configuration and
>management.
>
>Thanks!
> 
>Cheers,
>Jeff
>
>On 3/21/17, 03:08, "Netconf on behalf of t.petch"
><netconf-bounces@ietf.org on behalf of ietfc@btconnect.com> wrote:
>
>    What interaction, if any, is there between
>    
>    draft-ietf-rtgwg-yang-key-chain-15.txt
>    This document describes the key chain YANG data model.
>    file "ietf-key-chain@2017-02-16.yang"
>    
>    currently in IETF Last Call, and
>    
>    draft-ietf-netconf-system-keychain-00
>    This document defines a YANG data module for a system-level keychain
>    mechanism
>    file "ietf-system-keychain@2016-07-08.yang"
>    
>    ?
>    
>    Tom Petch
>    
>    
>    ----- Original Message -----
>    From: "Mehmet Ersue" <mersue@gmail.com>
>    To: "'Benoit Claise'" <bclaise@cisco.com>; "'Susan Hares'"
>    <shares@ndzh.com>
>    Sent: Monday, March 20, 2017 4:32 PM
>    
>    > 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 <mjethanandani@gmail.com>
>    >
>    >     Mehmet Ersue <mersue@gmail.com>
>    >
>    >
>    >
>    > Operations and Management Area Directors:
>    >
>    >      Benoit Claise <bclaise@cisco.com>
>    >
>    >      Joel Jaeggli <joelja@bogus.com>
>    >
>    >
>    >
>    > Operations and Management Area Advisor:
>    >
>    >      Benoit Claise <bclaise@cisco.com>
>    >
>    >
>    >
>    > Mailing Lists:
>    >
>    >      General Discussion: netconf@ietf.org
>    >
>    >      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:bclaise@cisco.com]
>    > Sent: Friday, March 17, 2017 4:49 PM
>    > To: Kent Watsen <kwatsen@juniper.net>; Mehmet Ersue
>    <mersue@gmail.com>;
>    > 'Susan Hares' <shares@ndzh.com>; 'Andy Bierman' <andy@yumaworks.com>
>    > Cc: 'Netconf' <netconf@ietf.org>
>    >
>    >
>    >
>    > 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
>    >
>    >
>    
>    <snip>
>    
>    
>    _______________________________________________
>    Netconf mailing list
>    Netconf@ietf.org
>    https://www.ietf.org/mailman/listinfo/netconf
>    
>
>
>_______________________________________________
>rtgwg mailing list
>rtgwg@ietf.org
>https://www.ietf.org/mailman/listinfo/rtgwg