[netconf] notification message comments

[Andy Bierman <[e-mail]>]

Hi,

1) message headers

There was some discussion in the interim meeting about the notification
headers.
This is not quite correct. There is only 1 hierarchical structure with
nested content.
This <notification> message is sent in addition to any transport headers.

- RFC 5277 defines the <notification> one-way message as an XML element.
- RFC8040 defines how this XML element is represented as a JSON object for
RESTCONF,
  using RFC 7951 JSON encoding.
- RFC 9254 defines how to encode the event as a CBOR map. There is no RFC
   defining a representation of the complete <notification> one-way message.

2) position-dependence

Since the event is an un-named child node, it cannot be modeled in YANG.
The parser relies on the order of the child nodes to parse the specific
event type.

3) co-existence with RFC 5277

I like the solutions proposed to allow a client to opt-in at the global
or subscription level.  However this is not enough.
The new one-way message cannot be named 'notification'.

A new message is needed to allow a receiver to cleanly process both old and
new message formats.

3) notification2 message

A new message with only two child nodes like RFC 5277, except replace
eventTime
with a 'header' container.

  sx:structure notification2 {
     container header {
         // new fields like sysName, sequence-id
         // eventTime and/or new timestamps
          // augments possible for extensibility
       }
       // event MUST follow, which matches the module/name of a notification
       // element or a top-level data node that has a nested event-type
    }


Andy