Benoit,
> On Oct 30, 2025, at 10:07 AM, [email protected] > <[email protected]> wrote: > As you noted below, there is an extra condition in the SAV case, "as a > discrete layer in the forwarding pipeline" as you describe it. > Somehow, this SAV case is more like the ForwardingStatus (IE 89) > In essence, the Metering Process can not report what it can not observe/loop > up/deduce. If we don't know why it's dropped, we can't report it. > This is an implicit statement in most of the IPFIX RFCs. As a kind of proof, > I looked up the 4 RFCs above, and there is only one occurrence of "Metering > Process". > > However, we should document your statements > I believe they would be a perfect fit for the "Operational Considerations", > RFC5706bis. Does it make sense? > Or do you have something else in mind, such as having the SAV drops in > draft-ietf-opsawg-discardmodel > <https://datatracker.ietf.org/doc/draft-ietf-opsawg-discardmodel/> and/or its > companion draft draft-evans-opsawg-ipfix-discard-class-ie-01 > <https://datatracker.ietf.org/doc/draft-evans-opsawg-ipfix-discard-class-ie/>? > As I mentioned in my original mail, I don't have specific recommendations. This is where those with deeper expertise than my own old experience in flow implementations will be helpful. There is strong overlap with the forwarding status IE, and also the discard options we're exploring for the discardclass draft. I can see that it may make sense for SAV cases for SAV enforcement to be emitted using those IEs since the enforcement are just special cases of existing behaviors. However, whether this can be practically accomplished depends on the implementation not only of the forwarding pipeline, but also the SAV mechanism. My early goal is thus more to highlight that discrete events may be challenging and should be discussed. With regard to operational considerations, here is my opinion on boilerplate text: It is often the case in standards documents that a particular subject matter should be discussed in consistent wording. Especially when it is the case that the matter is not the primary subject of the document, nor particular expertise of the authors, it is better that there be consistency in how that matter is discussed. Having pre-defined recipes provided by subject matter experts for such important language is useful. Requiring it to be incorporated in a document not primarily about that subject matter is distracting and repetitious. Referencing well known sources is great! My favorite example of success for such things is RFC 4949 for Internet security. So, using this as an example, I'm highly supportive of a broad IPFIX operational considerations document that can be referenced in various documents. -- Jeff
_______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
