Thanks Joe. In producing this draft, we explored several options to present the information model, including UML. Med suggested representing the information model as an abstracted data model in YANG, leveraging RFC 8791 - YANG Data Structure Extensions.
While I'm not an expert in either UML or YANG, we knew what we wanted to achieve: representing discard classification in a programmatic, easily understood manner that is agnostic of implementation yet unambiguous for implementers. Representing the information model in YANG has helped us achieve that goal, whereas UML did not. Adding a UML version of the information model to the draft now would not accelerate progress. The "information modelling in UML, data modelling in YANG" demarcation does not seem useful in this case. This community is more familiar with YANG, and it allows for lossless translation from information model to data model, enabling us to progress faster. I think the distinction should be in the applicability statement for the model rather than the modelling language used. As a newcomer to IETF processes, I also don't fully understand the distinction between an informational RFC for the information model and a standards track RFC for the data model. If we consider this draft, it could reasonably be implemented as data models in both YANG and IPFIX. If we had a use case to change the discard reporting in the YANG data model, for example, wouldn't it be reasonable to update the information model accordingly and consider propagating those changes to IPFIX? I'm unsure why we would apply a lower level of standardization to the information model than the data model; this seems better considered as a case-specific decision. Cheers John From: "Joe Clarke (jclarke)" <[email protected]> Date: Tuesday, 23 July 2024 at 20:35 To: "[email protected]" <[email protected]> Subject: [OPSAWG]How to move draft-ietf-opsawg-discardmodel forward It was discussed in the opsawg meeting how this draft should move forward. It’s great to see vendors taking this info model to the data model phase and implementing it! My struggle as chair was that this document is currently an informational document but uses standard conventions for YANG. It has also been raised in older proceedings that YANG is a data modeling language and languages like UML should be used for info models. That said, I like what Oscar said at the mic about having a common language for info and data models, and YANG does seem to fit in this case. Rob said in chat (and Med and I agree) that making this a Standard Track document wouldn’t hurt and would adhere to existing YANG guidelines. We can vet this with a broader YANG Doctors review, and we welcome other thoughts on the list. Joe Amazon Data Services UK Limited. Registered in England and Wales with registration number 09959151 with its registered office at 1 Principal Place, Worship Street, London, EC2A 2FA, United Kingdom. _______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
