After some more thinking, I prefer option 2 (i.e., keeping the IPFIX work separate). One of the biggest reasons I think is that it will be easier to have experts review the draft. I am not strongly opposed to option 3, but it feels like needlessly combining work.
Joe From: Evans, John <jevan...@amazon.co.uk> Date: Wednesday, March 26, 2025 at 08:29 To: Mahesh Jethanandani <mjethanand...@gmail.com>, Evans, John <jevanamz=40amazon.co...@dmarc.ietf.org> Cc: mohamed.boucad...@orange.com <mohamed.boucad...@orange.com>, Benoit Claise <benoit.cla...@huawei.com>, opsawg@ietf.org <opsawg@ietf.org>, opsawg-cha...@ietf.org <opsawg-cha...@ietf.org>, Jeff Haas <jh...@juniper.net>, Pylypenko, Oleksandr <o...@amazon.com>, Rob Wilton (rwilton) <rwil...@cisco.com>, draft-ietf-opsawg-discardmo...@ietf.org <draft-ietf-opsawg-discardmo...@ietf.org> Subject: Re: [OPSAWG]Re: draft-ietf-opsawg-discardmodel Hi Mahesh, Thanks for your feedback. Given we have the other draft, option 3 is relatively straightforward to do - albeit it feels a bit unwieldy. Any other feedback from the group? Cheers John On 21/03/2025, 22:34, "Mahesh Jethanandani" <mjethanand...@gmail.com <mailto:mjethanand...@gmail.com>> wrote: [Speaking as a contributor] Hi John, The advantage that I see with Option 3, and the reason I believe Rob suggested is that if there is change in the IM model, you would need to update both YANG and the IPFIX model. From a tracking perspective, it would be easier to do that if they are all in the same draft. Cheers. > On Mar 22, 2025, at 4:56 AM, Evans, John > <jevanamz=40amazon.co...@dmarc.ietf.org > <mailto:40amazon.co...@dmarc.ietf.org>> wrote: > > Hi All, > > Based on feedback from the last meeting we moved from option 1 to option 2 > below. Rob Wilton proposed option 3 in the discussion at the WG meeting this > week. Hence, we would like to solicit feedback from the group on whether > there is consensus with the current approach (option 2 below), or whether > there is support to transition to option 3. > > As an author, I think there's value both in separating concerns and in making > incremental progress, hence my preference is to stick with option 2, > > 1. Previous approach: separate drafts for each IM and DM, e.g. > a. draft-ietf-opsawg-discardmodel > i. IM (YANG) > b. draft-ietf-opsawg-… > i. IM (references draft-ietf-opsawg-discardmodel) > ii. DM (YANG) > c. draft-evans-opsawg-ipfix-discard-class-ie > i. IM (references draft-ietf-opsawg-discardmodel) > ii. DM (IPFIX IE) > > 2. Current approach: one draft for YANG IM and YANG DM with other DMs in > subsequent drafts: > a. draft-ietf-opsawg-discardmodel: > i. IM (YANG) > ii. DM (YANG) > b. draft-evans-opsawg-ipfix-discard-class-ie > i. IM (references draft-ietf-opsawg-discardmodel) > ii. DM (IPFIX IE) > > 3. Alternative approach proposed by Rob Wilton: single draft for IMs and DMs, > e.g. > a. draft-ietf-opsawg-discardmodel > i. IM (YANG) > ii. DM (YANG) > iii. DM (IPFIX IE) > > cheers > > John > > > ----------------------- > From: "Evans, John" <jevan...@amazon.co.uk <mailto:jevan...@amazon.co.uk>> > Date: Tuesday 4 March 2025 at 10:29 > To: "mohamed.boucad...@orange.com <mailto:mohamed.boucad...@orange.com>" > <mohamed.boucad...@orange.com <mailto:mohamed.boucad...@orange.com>>, Benoit > Claise <benoit.cla...@huawei.com <mailto:benoit.cla...@huawei.com>>, > "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>>, Jeff Haas <jh...@juniper.net > <mailto:jh...@juniper.net>>, "Pylypenko, Oleksandr" <o...@amazon.com > <mailto:o...@amazon.com>> > Cc: "draft-ietf-opsawg-discardmo...@ietf.org > <mailto:draft-ietf-opsawg-discardmo...@ietf.org>" > <draft-ietf-opsawg-discardmo...@ietf.org > <mailto:draft-ietf-opsawg-discardmo...@ietf.org>> > Subject: Re: draft-ietf-opsawg-discardmodel > > Hi All, > > We've checked in a updated version of draft-ietf-opsawg-discardmodel. The > most significant change is that it incorporates both the YANG information > model, and the YANG data model derived from the information model – as was > proposed after the last meeting: > https://datatracker.ietf.org/doc/draft-ietf-opsawg-discardmodel/ > <https://datatracker.ietf.org/doc/draft-ietf-opsawg-discardmodel/> > > We have also checked in a complementary draft, which defines a new IPFIX > Information Element for classifying flow-level discards that aligns with the > information model defined in draft-ietf-opsawg-discardmodel: > https://datatracker.ietf.org/doc/draft-evans-opsawg-ipfix-discard-class-ie/ > <https://datatracker.ietf.org/doc/draft-evans-opsawg-ipfix-discard-class-ie/> > > We would appreciate feedback from the group to see if we have consensus on > this approach, i.e.: > 1. draft-ietf-opsawg-discardmodel: > a. IM (YANG) > b. DM (YANG) > 2. draft-evans-opsawg-ipfix-discard-class-ie > a. IM (references draft-ietf-opsawg-discardmodel) > b. DM (IPFIX IE) > > The alternative would be to have a discrete draft for the information model, > e.g.: > > 1. draft-ietf-opsawg-discardmodel > a. IM (YANG) > 2. draft-ietf-opsawg-… > a. IM (references draft-ietf-opsawg-discardmodel) > b. DM (YANG) > 3. draft-evans-opsawg-ipfix-discard-class-ie > a. IM (references draft-ietf-opsawg-discardmodel) > b. DM (IPFIX IE) > > > Cheers > > John > > > From: "Evans, John" <jevan...@amazon.co.uk <mailto:jevan...@amazon.co.uk>> > Date: Friday 22 November 2024 at 13:43 > To: "mohamed.boucad...@orange.com <mailto:mohamed.boucad...@orange.com>" > <mohamed.boucad...@orange.com <mailto:mohamed.boucad...@orange.com>>, Benoit > Claise <benoit.cla...@huawei.com <mailto:benoit.cla...@huawei.com>>, > "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>>, Jeff Haas <jh...@juniper.net > <mailto:jh...@juniper.net>>, "Pylypenko, Oleksandr" <o...@amazon.com > <mailto:o...@amazon.com>> > Cc: "draft-ietf-opsawg-discardmo...@ietf.org > <mailto:draft-ietf-opsawg-discardmo...@ietf.org>" > <draft-ietf-opsawg-discardmo...@ietf.org > <mailto:draft-ietf-opsawg-discardmo...@ietf.org>> > Subject: Re: draft-ietf-opsawg-discardmodel > Resent from: <alias-boun...@ietf.org <mailto:alias-boun...@ietf.org>> > Resent to: <akad...@cisco.com <mailto:akad...@cisco.com>>, > <jevan...@amazon.co.uk <mailto:jevan...@amazon.co.uk>>, <jh...@juniper.net > <mailto:jh...@juniper.net>>, <mohamed.boucad...@orange.com > <mailto:mohamed.boucad...@orange.com>>, <o...@amazon.com > <mailto:o...@amazon.com>> > Resent date: Friday 22 November 2024 at 13:42 > > Hi Med / Benoit / Jeff / All, > > I agree re option 2. If there are no objections we’ll refactor the draft on > that basis. > > Cheers > > John > > From: "mohamed.boucad...@orange.com <mailto:mohamed.boucad...@orange.com>" > <mohamed.boucad...@orange.com <mailto:mohamed.boucad...@orange.com>> > Date: Friday 22 November 2024 at 07:35 > To: Benoit Claise <benoit.cla...@huawei.com > <mailto:benoit.cla...@huawei.com>>, "Evans, John" <jevan...@amazon.co.uk > <mailto:jevan...@amazon.co.uk>>, "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: "draft-ietf-opsawg-discardmo...@ietf.org > <mailto:draft-ietf-opsawg-discardmo...@ietf.org>" > <draft-ietf-opsawg-discardmo...@ietf.org > <mailto:draft-ietf-opsawg-discardmo...@ietf.org>> > Subject: RE: [EXTERNAL] draft-ietf-opsawg-discardmodel > Resent from: <alias-boun...@ietf.org <mailto:alias-boun...@ietf.org>> > Resent to: <akad...@cisco.com <mailto:akad...@cisco.com>>, > <jevan...@amazon.co.uk <mailto:jevan...@amazon.co.uk>>, <jh...@juniper.net > <mailto:jh...@juniper.net>>, <mohamed.boucad...@orange.com > <mailto:mohamed.boucad...@orange.com>>, <o...@amazon.com > <mailto:o...@amazon.com>> > Resent date: Friday 22 November 2024 at 07:35 > > Hi Benoît, all, > > I think that I can convince myself that option 2 is better here (have both > IM/DM in the same spec). The main challenge will be to find “where” to anchor > the nodes (interface, NE, routing management, etc.). Otherwise, I expect the > structures/groupings we already have in the IM will be reused nicely. > However, we will need to register the IM as well as we need to import it. > > I’m not sure to understand the last part of the following: > > == > 3. Should information models specified in YANG also be registered in IANA? > This is where we might have different views. As mentioned during the meeting: > "If you have it in IANA, then people will expect tooling to work.". > = > > The tooling (pyang, etc.) still work even with the current IM in the draft. > Also, the module can be imported/augmented/etc. > > Please note that even **fake** modules were registered! Think about > ietf-template for example: > > == > ietf-template ietf-templ...@2010-05-18.yang > <mailto:ietf-templ...@2010-05-18.yang> N > urn:ietf:params:xml:ns:yang:ietf-template temp [RFC6087] > === > > Thank you. > > Cheers, > Med > > De : Benoit Claise <benoit.cla...@huawei.com > <mailto:benoit.cla...@huawei.com>> > Envoyé : jeudi 21 novembre 2024 18:22 > À : Joe Clarke (jclarke) <jcla...@cisco.com <mailto:jcla...@cisco.com>>; > Evans, John <jevan...@amazon.co.uk <mailto:jevan...@amazon.co.uk>>; > opsawg@ietf.org <mailto:opsawg@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>>; BOUCADAIR Mohamed > INNOV/NET <mohamed.boucad...@orange.com > <mailto:mohamed.boucad...@orange.com>>; Aviran Kadosh (akadosh) > <akad...@cisco.com <mailto:akad...@cisco.com>> > Objet : Re: draft-ietf-opsawg-discardmodel > > > Dear all, > > Joe and I spoke. As we see it, there are multiple questions here. > > 1. Is the IETF interested into standardizing information models? > As mentioned by Mahesh (in the OPSAWG meeting minutes, to be posted soon): > "generally we don't spend too much time on info models and work on > standardise data models". However, we believe, as we accepted the discard > information as WG document already, let's not revisit this decision. > > 2. How should those information models be specified? > Could be text, UML, whatever. > YANG is also a possibility (even if not common practice) as YANG is a data > modeling language. As John mentioned during the meeting, one argument in the > favor of YANG is that it's well known. > > 3. Should information models specified in YANG also be registered in IANA? > This is where we might have different views. As mentioned during the meeting: > "If you have it in IANA, then people will expect tooling to work.". > > What do we do from here? > 1. Information model published as informational document: YANG model in an > appendix, not normative. In such a case, you don't register the YANG module > in IANA. > 2. Information and data models in a single standards-track document, with the > data model registered as a YANG module with IANA. > > Number 2 might be better, as you mentioned that there are existing > implementations. Plus it might ease maintainability and give other > implementations something to root to and augment. This might also be the path > of least resistance to publish. The YANG model in IANA would also justify the > fact that you moved from Informational to Standard Track in this version > (https://datatracker.ietf.org/doc/draft-ietf-opsawg-discardmodel/03/ > <https://datatracker.ietf.org/doc/draft-ietf-opsawg-discardmodel/03/>) > > 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. > > 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 mailto:jevan...@amazon.co.uk <mailto:jevan...@amazon.co.uk> > Date: Wednesday, November 13, 2024 at 06:53 > To: mailto:opsawg@ietf.org <mailto:opsawg@ietf.org> mailto:opsawg@ietf.org > <mailto:opsawg@ietf.org>, mailto:opsawg-cha...@ietf.org > <mailto:opsawg-cha...@ietf.org> mailto:opsawg-cha...@ietf.org > <mailto:opsawg-cha...@ietf.org> > Cc: Pylypenko, Oleksandr mailto:o...@amazon.com <mailto:o...@amazon.com>, > Jeff Haas mailto:jh...@juniper.net <mailto:jh...@juniper.net>, > mailto:mohamed.boucad...@orange.com <mailto:mohamed.boucad...@orange.com> > mailto:mohamed.boucad...@orange.com <mailto:mohamed.boucad...@orange.com>, > Aviran Kadosh (akadosh) mailto: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. > > ____________________________________________________________________________________________________________ > 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. > > > > > > > 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> 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
