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

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

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

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

 - supported-excluded-change-type
   - this union has overlapping enumeration implied values
    suggest assigning value -2; and value -1; to none and all enums

Andy

On Tue, Jan 7, 2020 at 5:04 AM Kent Watsen <kent+ietf@watsen.net> 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, internet-drafts@ietf.org 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.
> >
> > IETF Secretariat.
> >
>
> _______________________________________________
> netconf mailing list
> netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>