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

Benoit Claise <bclaise@cisco.com> Sun, 24 March 2019 16:55 UTC

Return-Path: <bclaise@cisco.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 521491200D7 for <netconf@ietfa.amsl.com>; Sun, 24 Mar 2019 09:55:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hyoi_yJt5i7Y for <netconf@ietfa.amsl.com>; Sun, 24 Mar 2019 09:55:30 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24D20126C15 for <netconf@ietf.org>; Sun, 24 Mar 2019 09:55:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12172; q=dns/txt; s=iport; t=1553446530; x=1554656130; h=to:cc:from:subject:message-id:date:mime-version; bh=mOGH9/dbbiL0fbPky+OxfBJ0d3NpRnkOlnJO9atSAyA=; b=CrXzm2GQjfIG4jbdi01D6f6TceNlUtkRbaymotvYMa1w6duC6IYMtUpY Lw+HBgLQmogAq0yScOPc5mDn1foW8mdxaXLZHgyGYgOst/Z4kUXJp6f94 vm80vA+jhqnKtNe3Jgr4E4H4lXT981nil4Varf7K5bK0S3p7knaPSC0Kv k=;
X-IronPort-AV: E=Sophos; i="5.60,256,1549929600"; d="scan'208,217"; a="10881273"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 Mar 2019 16:55:27 +0000
Received: from [10.61.80.17] (ams3-vpn-dhcp4114.cisco.com [10.61.80.17]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTP id x2OGtRJX012014; Sun, 24 Mar 2019 16:55:27 GMT
To: NETCONF <netconf@ietf.org>
From: Benoit Claise <bclaise@cisco.com>
Message-ID: <af75df03-db45-eaae-523d-58eceffe118d@cisco.com>
Date: Sun, 24 Mar 2019 17:55:27 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.3
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------F4DC043C21F1B5A1F9018B21"
Content-Language: en-US
X-Outbound-SMTP-Client: 10.61.80.17, ams3-vpn-dhcp4114.cisco.com
X-Outbound-Node: aer-core-2.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/5zefrHdwxDxgBsM6CUJEs0T4qdQ>
Subject: [netconf] draft-ietf-netconf-notification-capabilities feedback
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 24 Mar 2019 16:55:34 -0000

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