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

From: Benoit Claise <[email-masked]>
Date: Sun, 24 Mar 2019 17:55:27 +0100

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

---

From: Balázs Lengyel <[email-masked]>
Date: Mon, 25 Mar 2019 23:21:30 +0000

Thanks for the comments, See below. Balazs

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

Dear all,

Here is my feedback on draft-ietf-netconf-notification-capabilities,
which I gave verbally to Balasz today.

1. per datastore

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

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.

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

complying to the [I-D.lengyel-netmod-yang-instance-data]. The

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:

EDITORIAL

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

If the information is

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

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

BALAZS: will try. Providing examples will
help.

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

- 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: +36-70-330-7909 email: [email-masked]