[netconf] draft-ietf-netconf-notification-capabilities feedback

[Benoit Claise <[e-mail]>]

Dear all,

Here is my feedback on draft-ietf-netconf-notification-capabilities 
<https://datatracker.ietf.org/doc/draft-ietf-netconf-notification-capabilities/>, 
which I gave verbally to Balasz today.

- we need the on-change capabilities for
     1. per datastore
     2. per YANG object(s), i.e. schema specifig
     3. per YANG instance

- We really would some nacm:node-instance-identifier examples (of the 3 
different use cases)

- happy to see that it applies to config and oper data.

- the only leaves I care about are:

       +--ro on-change-notification-capability* [node-selector]
          +--ro node-selector               nacm:node-instance-identifier
          +--ro on-change-notification-sent    boolean

And because I need the default:

       +--ro notification-sent-for-config-default?   boolean
       +--ro notification-sent-for-state-default?    boolean

The rest below seems to be implementation specific (limitations):

       +--ro minimum-dampening-period?               uint32
       +--ro (update-period)?
       |  +--:(minimum-update-period)
       |  |  +--ro minimum-update-period?                  uint32
       |  +--:(supported-update-period)
       |     +--ro supported-update-period*                uint32
       +--ro max-objects-per-update?                 uint32


- The choice default values should be discussed. They 
implementation-specific.

      leaf notification-sent-for-config-default {
        type boolean;
        default true;
        description "Specifies the default value for
          top level configuration data nodes for the
          on-change-notification-sent capability.";
      }

      leaf notification-sent-for-state-default {
        type boolean;
        default false;
        description "Specifies the default value
          top level state data nodes for the
          on-change-notification-sent capability.";

Initially, I was thinking that both should be false, so that only 
on-change true must be present in the list.

- Not sure why the draft tries to go in the compliance statement of you 
MUST support both options

  The information SHALL be provided in two ways both following the
    ietf-notification-capabilities module:

    o  It SHALL be provided by the implementer as YANG instance data file
       complying to the [I-D.lengyel-netmod-yang-instance-data  <https://tools.ietf.org/html/draft-ietf-netconf-notification-capabilities-01#ref-I-D.lengyel-netmod-yang-instance-data>].  The
       file SHALL be available already in implementation time retrievable
       in a way that does not depend on a live network node.  E.g.
       download from product Website.

    o  It SHALL be available via NETCONF or RESTCONF from the live YANG
       server during runtime.

The specifications should document:
If you want this info off-line, then use 
draft-ietf-netmod-yang-instance-file-format
If you want this info on-line, implement the module in the server, 
potentially as an extension to the IETF-YANG-LIBRARY
MUST implement one of the two.


EDITORIAL
- When I see "instance", I always wonder if you mean an instantation or 
the instance-file-format

    If the information is
    not available early in some document, but only as instance data from
    the network node, the NMS implementation will be delayed, because it
    has to wait for the network node to be ready.

- This explanation could be improved (read it multiple times)

      On-change notifications SHALL be sent for a config=true
      data node if one of the following is true:
      - if it is a top level data-node and is not specified in the
      on-change-notification-capability list and the
      notification-sent-for-config-default is true; or
      - notifications are sent for its parent data node and it is
      not specified in the on-change-notification-capability list; or
      - it is specified in the on-change-notification-capability
      list and has a on-change-notification-sent value true.

      On-change notifications SHALL be sent for a config=false
      data node if one of the following is true:
      - if it is a top level data-node or has a config=true parent
      data node and is not specified in the
      on-change-notification-capability list and the
      notification-sent-for-state-default is true; or
      - notifications are sent for its parent data node
      which is also config=false and it is
      not specified in the on-change-notification-capability list; or
      - it is specified in the on-change-notification-capability
      list and has an on-change-notification-sent value true or
      ";

- why don't you just mention "on-change streaming capability discovery"

    Run-time information is needed

    o  for any "purely model driven" client, e.g. a NETCONF-browser.  As
       long as it has a valid model to read the capability information,
       it does not care which data nodes send notification, it will just
       handle what is available.

    o  in case the capability might change during run-time e.g. due to
       licensing, HW constraints etc.

    o  to check that early, implementation time capability information
       about the capabilities is indeed what the server implements (is
       the supplied documentation correct?)

- The terminology seems to focus on NETCONF, however it should stress 
the generic streaming capabilities

Regards, Benoit