Hi,
Small preference for option 2, reason being the unwieldy aspect of option 3.
And having to push 2 documents together is nothing new.
Regards,Reshad.
On Thursday, March 27, 2025 at 02:25:07 PM GMT+1, Evans, John
<[email protected]> wrote:
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" <[email protected]
<mailto:[email protected]>> 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
> <[email protected]
> <mailto:[email protected]>> 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" <[email protected] <mailto:[email protected]>>
> Date: Tuesday 4 March 2025 at 10:29
> To: "[email protected] <mailto:[email protected]>"
> <[email protected] <mailto:[email protected]>>, Benoit
> Claise <[email protected] <mailto:[email protected]>>,
> "[email protected] <mailto:[email protected]>" <[email protected]
> <mailto:[email protected]>>, "[email protected]
> <mailto:[email protected]>" <[email protected]
> <mailto:[email protected]>>, Jeff Haas <[email protected]
> <mailto:[email protected]>>, "Pylypenko, Oleksandr" <[email protected]
> <mailto:[email protected]>>
> Cc: "[email protected]
> <mailto:[email protected]>"
> <[email protected]
> <mailto:[email protected]>>
> 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" <[email protected] <mailto:[email protected]>>
> Date: Friday 22 November 2024 at 13:43
> To: "[email protected] <mailto:[email protected]>"
> <[email protected] <mailto:[email protected]>>, Benoit
> Claise <[email protected] <mailto:[email protected]>>,
> "[email protected] <mailto:[email protected]>" <[email protected]
> <mailto:[email protected]>>, "[email protected]
> <mailto:[email protected]>" <[email protected]
> <mailto:[email protected]>>, Jeff Haas <[email protected]
> <mailto:[email protected]>>, "Pylypenko, Oleksandr" <[email protected]
> <mailto:[email protected]>>
> Cc: "[email protected]
> <mailto:[email protected]>"
> <[email protected]
> <mailto:[email protected]>>
> Subject: Re: draft-ietf-opsawg-discardmodel
> Resent from: <[email protected] <mailto:[email protected]>>
> Resent to: <[email protected] <mailto:[email protected]>>,
> <[email protected] <mailto:[email protected]>>, <[email protected]
> <mailto:[email protected]>>, <[email protected]
> <mailto:[email protected]>>, <[email protected]
> <mailto:[email protected]>>
> 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: "[email protected] <mailto:[email protected]>"
> <[email protected] <mailto:[email protected]>>
> Date: Friday 22 November 2024 at 07:35
> To: Benoit Claise <[email protected]
> <mailto:[email protected]>>, "Evans, John" <[email protected]
> <mailto:[email protected]>>, "[email protected] <mailto:[email protected]>"
> <[email protected] <mailto:[email protected]>>, "[email protected]
> <mailto:[email protected]>" <[email protected]
> <mailto:[email protected]>>
> Cc: "[email protected]
> <mailto:[email protected]>"
> <[email protected]
> <mailto:[email protected]>>
> Subject: RE: [EXTERNAL] draft-ietf-opsawg-discardmodel
> Resent from: <[email protected] <mailto:[email protected]>>
> Resent to: <[email protected] <mailto:[email protected]>>,
> <[email protected] <mailto:[email protected]>>, <[email protected]
> <mailto:[email protected]>>, <[email protected]
> <mailto:[email protected]>>, <[email protected]
> <mailto:[email protected]>>
> 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 [email protected]
> <mailto:[email protected]> N
> urn:ietf:params:xml:ns:yang:ietf-template temp [RFC6087]
> ===
>
> Thank you.
>
> Cheers,
> Med
>
> De : Benoit Claise <[email protected]
> <mailto:[email protected]>>
> Envoyé : jeudi 21 novembre 2024 18:22
> À : Joe Clarke (jclarke) <[email protected] <mailto:[email protected]>>;
> Evans, John <[email protected] <mailto:[email protected]>>;
> [email protected] <mailto:[email protected]>; [email protected]
> <mailto:[email protected]>
> Cc : Pylypenko, Oleksandr <[email protected] <mailto:[email protected]>>; Jeff
> Haas <[email protected] <mailto:[email protected]>>; BOUCADAIR Mohamed
> INNOV/NET <[email protected]
> <mailto:[email protected]>>; Aviran Kadosh (akadosh)
> <[email protected] <mailto:[email protected]>>
> 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:[email protected] <mailto:[email protected]>
> Date: Wednesday, November 13, 2024 at 06:53
> To: mailto:[email protected] <mailto:[email protected]> mailto:[email protected]
> <mailto:[email protected]>, mailto:[email protected]
> <mailto:[email protected]> mailto:[email protected]
> <mailto:[email protected]>
> Cc: Pylypenko, Oleksandr mailto:[email protected] <mailto:[email protected]>,
> Jeff Haas mailto:[email protected] <mailto:[email protected]>,
> mailto:[email protected] <mailto:[email protected]>
> mailto:[email protected] <mailto:[email protected]>,
> Aviran Kadosh (akadosh) mailto:[email protected] <mailto:[email protected]>
> 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 -- [email protected] <mailto:[email protected]>
> To unsubscribe send an email to [email protected]
> <mailto:[email protected]>
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]
_______________________________________________
OPSAWG mailing list -- [email protected]
To unsubscribe send an email to [email protected]
