Re: [Netconf] Draft Charter Proposal for NETCONF WG

On 3/22/17, 5:27 PM, "Mahesh Jethanandani" <mjethanandani@gmail.com> wrote:

>
>
>> On Mar 21, 2017, at 10:09 AM, Acee Lindem (acee) <acee@cisco.com> wrote:
>> 
>> 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”.
>
>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?

As the original author and editor, I feel this is totally unnecessary. Of
course, if you want to add this to the ietf-keystore model draft, I would
not be oppose the reference.

Thanks,
Acee 

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