Re: [netconf] New Version Notification - draft-ietf-netconf-notification-capabilities-09.txt

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

Thanks for the comments. See below. Balazs

 

From: netconf <[e-mail]> On Behalf Of Andy Bierman
Sent: 2020. január 8., szerda 5:46
To: Kent Watsen <[e-mail]>
Cc: NETCONF Working Group <[e-mail]>
Subject: Re: [netconf] New Version Notification - draft-ietf-netconf-notification-capabilities-09.txt

 

Hi,

 

I think the new system capabilities module is good enough.

The node-instance-identifier type allows a key to be missing, which provides some entry reuse.

 

My concerns are with the notification capabilities module.

 

  - notification-support:  why is this an enumeration instead of bits?

 

suggest:

 

     typedef notification-support {

        type bits {
          bit notifications-for-config-changes-supported {
            description "The publisher is capable of sending
              notifications for config=true nodes, but not
              for config=false nodes for the relevant scope
              and subscription type." ;
          }
          bit notifications-for-state-changes-supported {
            description "The publisher is capable of sending
              notifications for config=false nodes, but not
              for config=true nodes for the relevant scope
              and subscription type." ;
          }
        }

   - can the names be shorter (config-changes, state-changes)?

    these names seem redundant and verbose

 

BALAZS:  OK changed to bits and shorter names

 

  - update-period

    this object seems implementation-specific. 

    The description should be less normative and use 2119 language

 

            A periodic subscription to the selected data nodes must

            specify a value that is at least as large or greater than
            this

 

      Suggest:  s/must/SHOULD/

BALAZS: OK changed to SHOULD. This is a requirement on the client so I though it is not an RFC2119 must or should

 

  - supported-update-period

    - this is very implementation-specific, especially as a leaf-list instead of a

      leaf with a range

    - also has 'must' language that is inappropriate; s/must/SHOULD/

BALAZS: OK changed to SHOULD. 

This is not implementation specific. E.g. the standard   3GPP TS 28.622 specifies that the system should declare a set of specific values (Not intervals) that are supported

 

 - max-objects-per-update

   - extremely implementation-specific; Does this assume a server generates updates

     by counting objects and stopping when this value is reached?

   - the text is not clear if it means objects or object instances? Do child nodes count

     as instances? IMO this object should be removed or changes to max. bytes per update

     (also implementation-specific)

BALAZS: RFC8641 defines:

     identity update-too-big {

       description

         "Periodic or on-change push update data trees exceed a maximum

          size limit.  Hints on the estimated size of what was too big

          may be returned as supplemental information.";

     }

This is the related capability. If you can get back a too-big error, then you should have a capability declaring what TOO-big means.

Bytes are risky. If the value of a string is updated from a single character to a 2 characters the subscription might become invalid 

as we have more bytes now. Also it is impossible to calculate the number of bytes as it depends on future instance data content.

You could say the same way that if we count data nodes, if a leaf-list gets one more entries the subscription could become invalid.

Still IMHO the best solution is to count the number of “data nodes”. I will change the description.

Also if the node can not a meaningful value it is free to omit the leaf.

 

 - supported-excluded-change-type

   - this union has overlapping enumeration implied values

    suggest assigning value -2; and value -1; to none and all enums

BALAZS: OOPS, will be corrected.

 

 

Andy

 

 

 

On Tue, Jan 7, 2020 at 5:04 AM Kent Watsen <[e-mail] <mailto:[e-mail]> > wrote:


Dear WG,

This is a fairly substantial update that defines a generic "ietf-system-capabilities’
module and a separate "ietf-notification-capabilities” module that augments into it.

We could start WGLC #2 now, but it would be good to get a few high-level reactions
from the WG before doing so.

Please provide comments as to if you believe the draft is ready for WGLC #2..

Thanks,
Kent // as shepherd


> On Jan 7, 2020, at 3:28 AM, [e-mail] <mailto:[e-mail]>  wrote:
> 
> 
> A new version (-09) has been submitted for draft-ietf-netconf-notification-capabilities:
> https://www.ietf.org/internet-drafts/draft-ietf-netconf-notification-capabilities-09.txt
> 
> 
> The IETF datatracker page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-netconf-notification-capabilities/
> 
> Diff from previous version:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-notification-capabilities-09
> 
> Please note that it may take a couple of minutes from the time of submission
> until the diff is available at tools.ietf.org <http://tools.ietf.org> .
> 
> IETF Secretariat.
> 

_______________________________________________
netconf mailing list
[e-mail] <mailto:[e-mail]> 
https://www.ietf.org/mailman/listinfo/netconf