As a contributor, I think a data model approach would be far more useful. That said, I haven’t seen these proprietary implementations based on your draft info model to understand how they deviate or what data modeling approach they take. I still think that starting with a YANG data model wouldn’t preclude future drafts standardizing IPFIX-based approaches to packet discard reporting (just as we’ve seen MIBs move to YANG).
As a chair, I think it would be easier from a process standpoint if this was a data model. There just isn’t a lot (any?) info models in the IETF developed in YANG. That said, things don’t always have to be easy, and Med has already commented having a YANG info model is not an insolvable problem. I know Benoît is a bit busy, and I’m sure he’ll want to weigh in next week. Joe From: Evans, John <jevan...@amazon.co.uk> Date: Wednesday, November 13, 2024 at 06:53 To: opsawg@ietf.org <opsawg@ietf.org>, opsawg-cha...@ietf.org <opsawg-cha...@ietf.org> Cc: Pylypenko, Oleksandr <o...@amazon.com>, Jeff Haas <jh...@juniper.net>, mohamed.boucad...@orange.com <mohamed.boucad...@orange.com>, Aviran Kadosh (akadosh) <akad...@cisco.com> Subject: draft-ietf-opsawg-discardmodel Hi All, Following last week's discussion in Dublin regarding draft-ietf-opsawg-discardmodel, we would appreciate feedback from the working group and chairs on how to proceed. To provide context, we initially defined an information model to establish a common framework for discard reporting that could be implemented across different data models, such as YANG and IPFIX. We selected YANG to define the information model for three key reasons: 1) the RFC8791 extensions enable the model to be decoupled from specific implementations; 2) this approach allows for lossless translation to a YANG-based data model; 3) the community has extensive experience with YANG. During the discussion, two main perspectives emerged: continue with the current approach of defining an information model; redefine the draft as a data model. Given that the information model is already in YANG, creating data models for interface, device, and control-plane would be straightforward. This could also serve as a reference for a future IPFIX-based discard reporting data model. Hence, we would appreciate feedback on whether the best path forward is to continue with the current information model approach or to refocus on developing data models instead? thanks John 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 -- opsawg@ietf.org To unsubscribe send an email to opsawg-le...@ietf.org
