Benoit,
> On Nov 21, 2024, at 12:22 PM, Benoit Claise > <benoit.claise=40huawei....@dmarc.ietf.org> wrote: > > Jeff, at the microphone during the OPSAWG meeting, mentioned the issue of > evolving/maintaining information models before going to a data model. We are > not too sure how publishing an information model as RFC (as opposed to a WIKI > or something similar) is actually helping out. To clarify what I intended to say, there's roughly two points. IM versioning and incentives to be generic: At the end of the day, if you have the same information that will manifest more than one way in an implementation, you have a versioning problem. If the informational model is the source of truth, each manifestation of the changes from one revision of the IM to the next have clear traceability in the implementations. You can clearly do the same thing by picking one of your implementations, like a data model, and using that as your source of truth. However, since data models may manifest rules that are not generic across manifestations, it becomes slightly more challenging to make sure that an update to the DM source of truth doesn't result in a second implementation with different rules from having issues. As a more concrete example, if you do something in a YANG DM that you can't model in a similarly useful enough way in IPFIX, it's a "problem". Does a stable IM prohibit such issues? Not necessarily. It means that you have an incentive in your IM work to ensure you can implement it appropriately. Traceability/Comparability: Knowing that elements in implementations are the same or at least comparable is useful. You can likely annotate > 1 implementation with something that documents comparability, but then you have "source of truth" conversations. As an example, think of how many things leveraged ifIndex from the IF-MIB. The MIB effectively became the source of truth for that semantic. Do we truly need to have an RFC for the IM? No. My desire is that we have practice that accommodates for the properties, above. -- Jeff > > Regards, Joe and Benoit > > On 11/13/2024 11:19 PM, Joe Clarke (jclarke) wrote: >> 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> <mailto:jevan...@amazon.co.uk> >> Date: Wednesday, November 13, 2024 at 06:53 >> To: opsawg@ietf.org <mailto:opsawg@ietf.org> <opsawg@ietf.org> >> <mailto:opsawg@ietf.org>, opsawg-cha...@ietf.org >> <mailto:opsawg-cha...@ietf.org> <opsawg-cha...@ietf.org> >> <mailto:opsawg-cha...@ietf.org> >> Cc: Pylypenko, Oleksandr <o...@amazon.com> <mailto:o...@amazon.com>, Jeff >> Haas <jh...@juniper.net> >> <mailto:jh...@juniper.net>,mohamed.boucad...@orange.com >> <mailto:mohamed.boucad...@orange.com> <mohamed.boucad...@orange.com> >> <mailto:mohamed.boucad...@orange.com>, Aviran Kadosh (akadosh) >> <akad...@cisco.com> <mailto: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 <mailto:opsawg@ietf.org> > To unsubscribe send an email to opsawg-le...@ietf.org > <mailto:opsawg-le...@ietf.org>
_______________________________________________ OPSAWG mailing list -- opsawg@ietf.org To unsubscribe send an email to opsawg-le...@ietf.org
