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

From: Balázs Lengyel <[email-masked]>
Date: Fri, 14 Feb 2020 10:03:21 +0000

See below. BALAZS

-----Original Message-----
From: Reshad Rahman (rrahman) <[email-masked]> 
Sent: 2020. január 25., szombat 17:23
To: [email-masked]; Balázs Lengyel <[email-masked]>
Subject: Re: [netconf] I-D Action: draft-ietf-netconf-notification-capabilities-10.txt

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).
BALAZS: OK. will add it into the acme router example. The loopback interface does not support any notifications.
- 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?
BALAZS: It might not make sense, but is OK. Anyway I will remove state.
 I will add to the typedef's description:
If the bit config-changes or state-changes is set 
          for a datastore or a set of nodes that does not contain 
          nodes with the indicated config value, 
          this has no effect, as if no support was declared. 
          E.g. indicating support for state-changes for 
          a candidate datastore has no effect. 
- In the 2nd example, why "config-changes" for in-octets and out-octets, should be state-changes only?
BALAZS: Doesn't matter whether config-changes is declared in this case, as these specific leaves are config=false. I will remove config-changes for simplicity.
- Page 21 the 2nd example has this: /if:interfaces/if:interface/if:statistics</node-selector>, typo? 
BALAZS: OK, updated
- 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)?
BALAZS: 
   datastore subscription capabilities: Not really needed, as they never change as stated above the example
   operational is on-change capable: no update needed. This is declared on system level.
Regards,
Reshad.

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

    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/
    
    _______________________________________________
    netconf mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/netconf