Re: [Netconf] Draft Charter Proposal for NETCONF WG

Tom

On 3/21/17, 12:38 PM, "t.petch" <ietfc@btconnect.com> wrote:

>---- Original Message -----
>From: "Acee Lindem (acee)" <acee@cisco.com>
>Sent: Tuesday, March 21, 2017 2:22 PM
>
>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.
>
><tp>
>Acee
>
>Yes, I had read them before posting; my point in quoting what I did was
>that from the YANG module name and the introduction to the I-Ds, they
>would appear to overlap, and you have to dig deeper to realise that they
>do not.  I think this misleading and so wrong.
>
>In the same vein, we have already discussed and agreed to disagree on
>'keychain' and 'key-chain'; again, misleading and I think wrong.

The latest version of the NETCONF draft refers to keystore rather than
keychain. 

https://datatracker.ietf.org/doc/html/draft-ietf-netconf-keystore

Hopefully, this has resolved any potential confusion and your concerns.
There are going to be modules that share common qualifiers. Consider “ip”,
“interface”, “system”, “oam”, and “topology”.

Thanks,
Acee

>
>As Andy said recently,  'YANG is supposed to be prioritized for readers,
>writers, and then tool-makers.' and I interpret one part of this as
>making life easy for the non-experts.
>
>Which I do not see our current approach, two I-Ds neither acknowledging
>the existence of the other, to key stores as doing.
>
>Tom Petch
>
>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
>