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

[Andy Bierman <[e-mail]>]

On Mon, Apr 22, 2024 at 12:39 PM Kent Watsen <[e-mail]> wrote:

> Hi Andy,
>
> I think the WG needs to agree on the requirements and a plan to go from
> RFC 5277 notification element to the example in the kafka draft.
>
> https://www.ietf.org/archive/id/draft-netana-nmop-yang-kafka-integration-01.html#push_change_update_notif_example_json_fig
>
>
> Fair point, but I think that there is only one requirement:
>    - to define YANG enabling the validation of RFC 5277 notifications.
>
>
Did you have more in mind?
>


Look at the example notification in
https://www.ietf.org/archive/id/draft-netana-nmop-yang-kafka-integration-01.txt

 {
  "ietf-notification:notification": {
    "eventTime": "2023-03-25T08:30:11.22Z",
    "ietf-notification-sequencing:sysName": "example-router",
    "ietf-notification-sequencing:sequenceNumber": 1,
    "ietf-subscribed-notification:subscription-started": {
      "id": 6666,
      "ietf-yang-push:datastore": "ietf-datastores:operational",
      "ietf-yang-push:datastore-xpath-filter": "/if:interfaces",
      "ietf-yang-push-revision:revision": "2014-05-08",
      "ietf-yang-push-revision:module-name": "ietf-interfaces",
      "ietf-yang-push-revision:revision-label": "",
      "ietf-distributed-notif:message-observation-domain-id": [1,2],
      "transport": "ietf-udp-notif-transport:udp-notif",
      "encoding": "encode-json",
      "ietf-yang-push:periodic": {
        "ietf-yang-push:period": 100
      }
    }
  }
}

The 'sysName' and 'sequenceNumber' are from the augment-structure in
https://datatracker.ietf.org/doc/html/draft-tgraf-netconf-notif-sequencing-03

The notification structure in
https://datatracker.ietf.org/doc/html/draft-ahuang-netconf-notif-yang-03
is not the problem.  That draft is trivial and obvious.  The larger
protocol and deployment issues
should also be obvious, but not trivial

NEW CLIENT:

How does the new client know what notification header will be used?

Is there one standard notification header or not? (Pros and Cons for either
way)
If not, then how is the new client supposed to know what the server
can/will send?
Can the client configure what the server will send?

Note that the 'notification' structure is a pure abstraction using a YANG
extension.
It MAY be invisible to a YANG 1.1 tool and is not related to any protocol
messages
(except by description-stmt).


OLD CLIENT

Server MUST use RFC5277 notification messages sent to old clients





> BTW, I almost wonder why this isn’t an rfc5277-bis.
>
>

Indeed.

If the goal is to actually send a notification message with a standard
protocol, then more work is needed.




> IMO this design is wrong.
> The extra data (if any) should be added to the push-update, not to the
> notification message header.
>
>
> What’s wrong?  The “notif-yang” draft only defines the “eventTime” leaf,
> which matches RFC 5277.  This scope seems right to me...
>
>

I meant the other drafts.
The issue here is whether the added data is needed in every notification or
just PUSH updates?
It could be both I guess.



>
> The example does not conform to the "NotificationType" XSD type in RFC
> 5277.
>
>     <!-- <Notification> operation -->
>      <xs:complexType name="NotificationContentType"/>
>
>     <xs:element name="notificationContent"
>         type="NotificationContentType" abstract="true"/>
>
>     <xs:complexType name="NotificationType">
>         <xs:sequence>
>             <xs:element name="eventTime" type="xs:dateTime">
>               <xs:annotation>
>                 <xs:documentation>
>                 The time the event was generated by the event source.
>                 </xs:documentation>
>               </xs:annotation>
>             </xs:element>
>             <xs:element ref="notificationContent"/>
>         </xs:sequence>
>     </xs:complexType>
>
>     <xs:element name="notification" type="NotificationType"/>
>
>
> Do you mean the *examples* in Appendix A?   What’s wrong?
>
>
The 'sysName' and 'sequenceNumber' elements are not allowed by the XSD.
The event type is a substitutionGroup. This element is expected to follow
the 'eventTime' leaf.



> Are you expecting an element called “event”?  I think that the “event”
> element used in RFC 5277 was just an example...
>
>
The XSD is clear.


> Or do you this draft to provide XSD for the ncEvent:notificationContent
> substitution group?
>
>
>
> I am concerned that 'augment-structure' will be used to create lots of
> different notification variants.
>
>
> The string “augment-structure” doesn’t appear in this draft.  Maybe you
> meant
> https://datatracker.ietf.org/doc/html/draft-tgraf-netconf-yang-push-observation-time-00
> ?
>
>
> I’m concerned about the "augment-structure” too, but for a different
> reason.  My reason is that, if I understand the proposal correctly,
> everywhere there is a “notification” in a YANG module, there would also
> have to be an “augment-structure”, which sounds just horrible.
>
> To be clear, my idea of "YANG enabling the validation of RFC 5277
> notifications” may entail some coding to stitch together something that a
> validator can use.  Having a fully-defined sx:structure seems unrealistic.
>
>
> Every vendor could make up their own protocol messages this way.
>
> 1) How does each protocol using the structure-based notification message
> define, advertise, negotiate
>     the actual message template used?
>
> 2) How does each protocol make sure that a client must opt-in somehow for
> the new format,
>     otherwise the strict RFC 5277 format is used?
>
>
> These are good questions.  Can the authors reply?
>
>
> Andy
>
>
> Kent
>
>
>
Andy