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

[Balázs Lengyel <[e-mail]>]

Thanks for the comments, See below. Balazs

On 2019. 03. 24. 17:55, Benoit Claise wrote:

Dear all,

Here is my feedback on https://datatracker.ietf.org/doc/draft-ietf-netconf-notification-capabilities/" rel="nofollow">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

BALAZS: per datastore to be added. per instance is possible  in the on-line data; while it is also possible in the off-line instance data files, it won't really work as usually the instance keys are not know that early.

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

BALAZS: will be provided

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

BALAZS: They are optional, you don't have to provide them. I was specifically asked to include them. I think it is useful, and it does no harm.

- 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.

BALAZS: I chose the defaults because in my view is that implementing config updates centrally is easy, while implementing state updates is a distributed task, thus complicated. The defaults can be changed by a deviation. If the WG has a strong opinion I can change them,

- 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 [https://tools.ietf.org/html/draft-ietf-netconf-notification-capabilities-01#ref-I-D.lengyel-netmod-yang-instance-data" title='"YANG Based Instance Data Files Format"' rel="nofollow">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.

BALAZS: I will change  this to say: The information SHOULD be provided in implementation time, but one of the above MUST be done.

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. 

BALAZS: I will use instance-data-set  or on-line for live data.

- 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
     ";

BALAZS: will try. Providing examples will help.

- 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

BALAZS: configuring on-change subscription is netconf (and restconf) related even if the transport of notifications may use different transports. Will clarify.

Regards, Benoit

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: [phone]              email: [e-mail]