Re: [Netconf] Draft Charter Proposal for NETCONF WG

[Mahesh Jethanandani <[e-mail]>]

> On Mar 21, 2017, at 10:09 AM, Acee Lindem (acee) <[e-mail]> wrote:
> 
> Tom
> 
>> On 3/21/17, 12:38 PM, "t.petch" <[e-mail]> wrote:
>> 
>> ---- 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.
> 
> 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”.

That should not be reason why we cannot clarify that the purpose of the keychain model is to deal with symmetric keys. And refer to keystore draft for asymmetric keys. 

Do you see a problem for calling out that distinction?

Mahesh 

> 
> 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"
>> <[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
> 
> _______________________________________________
> Netconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf