What I heard at the mic was it would be good to have an example implementation/DM in the appendix of the document. That might help to shake out more comments. On top of that, I’d like to see the doc moved to PS and then I want to get a YANG Doctors review.
I think after letting those changes sit, we could consider a WG LC. Joe From: Evans, John <jevan...@amazon.co.uk> Date: Wednesday, July 24, 2024 at 15:29 To: mohamed.boucad...@orange.com <mohamed.boucad...@orange.com>, Joe Clarke (jclarke) <jcla...@cisco.com>, opsawg@ietf.org <opsawg@ietf.org> Subject: Re: [OPSAWG]Re: How to move draft-ietf-opsawg-discardmodel forward Thanks Joe and Med. What should we do as next steps? Cheers John From: "mohamed.boucad...@orange.com" <mohamed.boucad...@orange.com> Date: Wednesday, 24 July 2024 at 17:48 To: "Joe Clarke (jclarke)" <jcla...@cisco.com>, "Evans, John" <jevan...@amazon.co.uk>, "opsawg@ietf.org" <opsawg@ietf.org> Subject: RE: [EXTERNAL] [OPSAWG]Re: How to move draft-ietf-opsawg-discardmodel forward CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. Hi Joe, all, As indicated in the meeting, PS seems the right approach here especially that future data models may reuse the structure/groupings in the discardmodel. Otherwise, this will be a downref. Thanks. Cheers, Med De : Joe Clarke (jclarke) <jclarke=40cisco....@dmarc.ietf.org> Envoyé : mercredi 24 juillet 2024 18:39 À : Evans, John <jevanamz=40amazon.co...@dmarc.ietf.org>; opsawg@ietf.org Objet : [OPSAWG]Re: How to move draft-ietf-opsawg-discardmodel forward First, I was out of sorts a bit yesterday. It was Diego at the mic on the use of YANG for info models. I want to be clear that I wasn’t suggesting you change your draft to use UML. I like the YANG use here. I was just concerned on the process ramifications of such. I have also seen normative references to info models (that are Informational), and it seems right to me, especially in this case given the fact that a YANG-based implementation might be transparent (and all the normative language in it), that this be a Standards track document. Joe From: Evans, John <jevanamz=40amazon.co...@dmarc.ietf.org<mailto:jevanamz=40amazon.co...@dmarc.ietf.org>> Date: Wednesday, July 24, 2024 at 05:28 To: Joe Clarke (jclarke) <jcla...@cisco.com<mailto:jcla...@cisco.com>>, opsawg@ietf.org<mailto:opsawg@ietf.org> <opsawg@ietf.org<mailto:opsawg@ietf.org>> Subject: Re: [OPSAWG]How to move draft-ietf-opsawg-discardmodel forward 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)" <jclarke=40cisco....@dmarc.ietf.org<mailto:jclarke=40cisco....@dmarc.ietf.org>> Date: Tuesday, 23 July 2024 at 20:35 To: "opsawg@ietf.org<mailto:opsawg@ietf.org>" <opsawg@ietf.org<mailto:opsawg@ietf.org>> 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. ____________________________________________________________________________________________________________ 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. 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
