Re: [Netconf] Draft Charter Proposal for NETCONF WG

[t.petch <[e-mail]>]

---- Original Message -----
From: "Acee Lindem (acee)" <[e-mail]>
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.

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"
<[e-mail] on behalf of [e-mail]> 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"
><[e-mail] on behalf of [e-mail]> 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 "[e-mail]"
>
>    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 "[e-mail]"
>
>    ?
>
>    Tom Petch
>
>
>    ----- Original Message -----
>    From: "Mehmet Ersue" <[e-mail]>
>    To: "'Benoit Claise'" <[e-mail]>; "'Susan Hares'"
>    <[e-mail]>
>    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 <[e-mail]>
>    >
>    >     Mehmet Ersue <[e-mail]>
>    >
>    >
>    >
>    > Operations and Management Area Directors:
>    >
>    >      Benoit Claise <[e-mail]>
>    >
>    >      Joel Jaeggli <[e-mail]>
>    >
>    >
>    >
>    > Operations and Management Area Advisor:
>    >
>    >      Benoit Claise <[e-mail]>
>    >
>    >
>    >
>    > Mailing Lists:
>    >
>    >      General Discussion: [e-mail]
>    >
>    >      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:[e-mail]]
>    > Sent: Friday, March 17, 2017 4:49 PM
>    > To: Kent Watsen <[e-mail]>; Mehmet Ersue
>    <[e-mail]>;
>    > 'Susan Hares' <[e-mail]>; 'Andy Bierman'
<[e-mail]>
>    > Cc: 'Netconf' <[e-mail]>
>    >
>    >
>    >
>    > 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
>    [e-mail]
>    https://www.ietf.org/mailman/listinfo/netconf
>
>
>
>_______________________________________________
>rtgwg mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/rtgwg