Re: [Netconf] Draft Charter Proposal for NETCONF WG

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