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

[Kent Watsen <[e-mail]>]

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?

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


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


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

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

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