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

[Andy Bierman <[e-mail]>]

On Fri, Jan 10, 2020 at 8:07 AM Balázs Lengyel <[e-mail]>
wrote:

>
>
>
>
> *From:* Andy Bierman <[e-mail]>
> *Sent:* 2020. január 10., péntek 16:48
>
> On Fri, Jan 10, 2020 at 4:16 AM Balázs Lengyel <
> [e-mail]> wrote:
>
> *See BALAZS2 below. *
>
>
>
> >   - 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/
>
> See above.
>
> What about the supported-update-period leaf-list?
>
> If a server allows any centi-second value from 1 sec to 1 hour then this
> will
>
> be a leaf-list with 5900 instances in it..  Since there is no reason to
> limit the upper-bound
>
> (e.g., client wants 1 statistics update per day) this leaf-list will
> likely have millions
>
> of instances in it.
>
>
>
> IMO this leaf-list should be removed. The minimum-update-period is
> sufficient.
>
>
>
> BALAZS2: There are implementations and standards that use specific values
> not ranges.
>
>
>
> The YANG-Push standard simply specifies "centiseconds" as the type.
>
> There is no mention in RFC 8641 of anything related to supporting a subset
> of this data type.
>
> The YANG syntax for "centiseconds" allows for 4 billion distinct values:
>
>
>
>            typedef centiseconds {
>
>        type uint32;
>
>        description
>
>          "A period of time, measured in units of 0.01 seconds.";
>
>      }
>
>
>
>
>
> IMO this object could be added via augment by a vendor or other SDO.
>
> It has no relevance to the YANG-Push standard.
>
>
>
> BALAZS3: RFC8641 defines: period centiseconds derived from uint32.
>
> However it does not say anything about whether an application should/shall support
>
> -        The full uint32 range
>
> -        Just some interval(s)
>
> -        Zero to a minimum value
>
> -        A specific set of values
>
>
RFC 7950 specifies the server requirements for typedefs, and the built-in
type uint32
The YANG-Push data-def-stmts make no mention of any different
interpretation of this data type.


> I could argue the same way that a set of specific values is enough, minimum is not needed and is not specified in RFC8641
>
> IMHO 3GPP is an important user  community, so if they are using specific values, we should allow for that in our model.
>
>

It is one thing for a client to configure a subset of values and quite
another
for a server to only accept a subset of the specified values.
YANG Push is not constrained to a subset of the centiseconds data type.


> I see value in allowing both a minimum value and specific values. Does it harm anyone to allow both?
>
>
It doesn't belong in the module for YANG-Push.
IMO you need to use a deviation to replace the data type because your
implementation
that only accepts a subset of centiseconds is non-compliant.  A client
should not have to
go read some unrelated capabilities objects to find out how a server
deviates from the spec.

BTW, the module names a top-level container called
'notification-capabilities' but none
of the contents are for generic notifications. They are all for YANG-Push.


Andy