Subject: [netconf] I-D Action: draft-ietf-netconf-notification-capabilities-10.txt

From: [email-masked]
Date: Thu, 16 Jan 2020 07:20:20 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network Configuration WG of the IETF.

        Title           : Generic YANG-related System Capabilities and YANG-Push Notification Capabilities
        Authors         : Balazs Lengyel
                          Alexander Clemm
                          Benoit Claise
	Filename        : draft-ietf-netconf-notification-capabilities-10.txt
	Pages           : 23
	Date            : 2020-01-15

Abstract:
   This document proposes two YANG modules.  The module ietf-system-
   capabilities provides a structure that can be used to specify any
   YANG related system capability.

   The module ietf-notification-capabilities allows a publisher to
   specify capabilities related to "Subscription to YANG Datastores"
   (YANG-Push).  It proposes to use YANG Instance Data to document this
   information and make it already available at implementation-time, but
   also allow it to be reported at run-time.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netconf-notification-capabilities/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-netconf-notification-capabilities-10
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-notification-capabilities-10

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-notification-capabilities-10

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Sat, 25 Jan 2020 16:23:06 +0000

Hi Balazs,

Questions/comments on the examples:
- My main comment is that the example section needs to be extended to address more use-cases. One of the reasons we didn't go with YANG model annotation is the need to express capabilities per-instance, we should have an example to illustrate that. (e.g. where 1 interface has different on-change capabilities than the default/others).
- Page 19-20 both examples have running datastore on-change-supported set to "config-changes state-changes". I don't think state-changes makes sense for running since state-changes is for config false nodes?
- In the 2nd example, why "config-changes" for in-octets and out-octets, should be state-changes only?
- Page 21 the 2nd example has this: /if:interfaces/if:interface/if:statistics</node-selector>, typo? 
- Second example, do we need a node-selector  entry to indicate that datastore subscription capabilities are not reported on-change? And an entry for / to indicate that operational is on-change capable (as in example 1)?

Regards,
Reshad.

On 2020-01-16, 10:21 AM, "netconf on behalf of [email-masked]" <[email-masked] on behalf of [email-masked]> wrote:

    
    Abstract:

    

    
    
    _______________________________________________
    netconf mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/netconf