[netconf] Re: Adoption call for notif-yang-04

[Andy Bierman <[e-mail]>]

On Fri, May 10, 2024 at 3:38 PM Kent Watsen <[e-mail]> wrote:

>
>
> On May 10, 2024, at 1:43 PM, Andy Bierman <[e-mail]> wrote:
>
> It is quite rigid and XML-specific:
>
>    <notification>
>        <eventTime>...</eventTime>
>        < **event element**  />
>    </notification>
>
> <snip/>
>
> YANG is incapable of representing this XSD correctly (no
> SubstitutionGroup).
>
>
> True, not even an “anydata” helps.  If the goal is to be able to validate
> the entire “notification” message, I don’t see how that’s possible.
>
>
IMO that is not the goal, especially since YANG does not support it
(without extensions).
JSON needs a module name for the notification and eventTime elements.
CBOR needs SID assignments for the same elements.

Another goal is to introduce a next-gen notification header that is based
on a structure + augments.
This is much better than a static and rigid header that is not allowed to
have any changes or additions.

YANG Push updates should support 3 types of data:
  1) metadata associated with the event
  2) extra server data gathered at the same time as the event
  3) event data

IMO not every notification on every server needs to add the "sysName" leaf.
It would be better if data of type (2) were configurable by the client.



> Code I’ve written in the past manually-validates the envelope and then,
> separately, validates the payload via the YANG “notification” definition.
>


All implementations have to deal with child nodes of certain "root" nodes
that magically appear in the schema tree.
(Where magic == some normative text in an RFC)

YANG/CBOR eliminates this problem with SIDs.


>
> K.
>
>
Andy