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

[Kent Watsen <[e-mail]>]

Hi Med,

> On Apr 18, 2024, at 9:45 AM, [e-mail] wrote:
> 
> Hi all,
> 
> I see the potential behind this spec to fill a gap (refer to draft-netana-nmop-yang-kafka-integration). However, as currently written, there is a disconnect between what is claimed in the abstract, the "simple" sx module, and the xml/json/cbor mappings in the appendix.

Hoping to understand this…

>   module: ietf-notification
> 
>     structure notification:
>       +-- eventTime    yang:date-and-time
> 
> It is true that there is no YANG module in RFC5277, but only an XML encoding.

RFC 5277 defines an XSD, which was in-fashion at the time, but outdated now…


> I would expect the authors to start from there and define a YANG module that echoes that XML structure + then enrich it with missing pieces (like eventTime) so that usual mapping specs naturally apply.

Consistent with RFC 5277, this draft defines only “eventTime”, only using YANG instead of XSD.


> I may be missing something, but some reasoning about the practicalities to produce data nodes and gluing it with other pieces is 5277 is needed.
> 
> For these reasons, I'm afraid that this version is not ready for adoption.

No comment on the above.


Circling back to my "Hoping to understand this…” comment, I don’t understand the purpose of the examples in the appendix.  As it seems that "how to encode" notifications in XML/JSON is well-understood, with the only missing piece being "how to validate” them, which is what this document enables, and so I was expecting to see an example illustrating that (to Andy’s point in another message, this draft should show the “augment-structure” syntax in use).  Also, why does this draft focus on CBOR/SIDs?


> Cheers,
> Med

K.


> 
>> -----Message d'origine-----
>> De : netconf <[e-mail]> De la part de Kent Watsen
>> Envoyé : dimanche 7 avril 2024 00:14
>> À : [e-mail]
>> Objet : [netconf] Adoption call for notif-yang-04
>> 
>> 
>> NETCONF WG,
>> 
>> This message starts a two week poll on adopting the following
>> document:
>> 
>> 	YANG model for NETCONF Event Notifications
>> 	https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
>> Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ahuang-netconf-notif-yang-
>> 04&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C211b4259f7534b07115
>> 208dc5686f24f%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63848038486
>> 1736143%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLC
>> JBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=dA8lFN7pH3tdAS7lRJph7D
>> iQ5wV98Ee1sKGIBgcFeKA%3D&reserved=0
>> 
>> The poll ends April 20.
>> 
>> Please send email to the list indicating "yes/support" or "no/do not
>> support".  If indicating no, please state your reservations with the
>> document.  If yes, please also feel free to provide comments you'd
>> like to see addressed once the document is a WG document.
>> 
>> No IPR is known for this document:
>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail
>> archive.ietf.org%2Farch%2Fmsg%2Fnetconf%2FoQVZ6Pf_novNfMB4RsnDxQibHpM%
>> 2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C211b4259f7534b07115
>> 208dc5686f24f%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63848038486
>> 1744910%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLC
>> JBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=spWoSRnrRPQ0lHPnD%2FTl
>> tr4wwzU7zn%2F1qxy5LBH1ujw%3D&reserved=0
>> 
>> PS: this document received strong support before, being very focused,
>> providing just a module enabling validation of YANG "notification"
>> messages.
>> 
>> Kent and Per (as co-chairs)
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> netconf mailing list
>> [e-mail]
>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
>> ietf.org%2Fmailman%2Flistinfo%2Fnetconf&data=05%7C02%7Cmohamed.boucada
>> ir%40orange.com%7C211b4259f7534b07115208dc5686f24f%7C90c7a20af34b40bfb
>> c48b9253b6f5d20%7C0%7C0%7C638480384861751307%7CUnknown%7CTWFpbGZsb3d8e
>> yJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%
>> 7C%7C%7C&sdata=BKneFQbHB2s9rbSVFulEULoxnperrKIwme1oCEvGW6Q%3D&reserved
>> =0
> ____________________________________________________________________________________________________________
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
>