Re: [IPFIX] errata eid7775 RE: [**EXTERNAL**] RE: WG LC: IPFIX documents
Benoit Claise <benoit.claise=40huawei.com-Tr9gZwTxerDR74oF6e/[email protected]> Tue, 6 Feb 2024 10:19:19 +0100
| Newsgroups | gmane.ietf.opsawg,gmane.ietf.tcpm,gmane.ietf.tsvwg |
|---|---|
| Message-ID | <[email protected]> |
Hi Andrew, What the document dated from 2011 mentions does not matter too much. What is key is the Cisco internal document that contains the Cisco IPFIX registry. So when I wrote " I don't feel comfortable having an errata on a Cisco-specific IPFIX", I actually meant: " I don't feel comfortable having an errata on a Cisco-specific IPFIX without Cisco approving this". Regards, Benoit On 2/5/2024 7:12 PM, Andrew Feren wrote: > > Hi Benoit, > > I see your point about not having an errata on a Cisco RFC. That > being said…. > > It appears that the IANA page has listed forwardingStatus(89) as > unsigned8 since 2018. Also CCO-NF9FMT > <http://www.cisco.com/en/US/technologies/tk648/tk362/technologies_white_paper09186a00800a3db9.html>, > the other cisco document referenced for forwardingStatus(89), is > pretty unambiguous that forwardingStatus(89) is 1 byte. Beyond that I > don’t have strong feelings about this. The different int sizes never > seemed all that useful to me anyway since mostly it is the size sent > in the template that matters. > > -Andrew > > *From: *IPFIX <[email protected]> on behalf of Benoit Claise > <benoit.claise=40huawei.com-Tr9gZwTxerDR74oF6e/[email protected]> > *Date: *Monday, February 5, 2024 at 12:37 PM > *To: *[email protected] <[email protected]>, > Aitken, Paul <[email protected]>, Joe Clarke (jclarke) > <[email protected]>, [email protected] <[email protected]> > *Cc: *[email protected] <[email protected]>, [email protected] <[email protected]>, > [email protected] <[email protected]>, [email protected] <[email protected]> > *Subject: *Re: [IPFIX] errata eid7775 RE: [**EXTERNAL**] RE: WG LC: > IPFIX documents > > [EXTERNAL] CAUTION: This email originated from outside of the > organization. Do not click links or open attachments unless you > recognize the sender and know the content is safe. > > Hi Paul, > > On 1/23/2024 12:14 PM, [email protected] wrote: > > 4.3. forwardingStatus > > In particular, the registered Abstract > Data Type is unsigned8, while it must be unsigned32. > > Why must it be? > > */[Med] As per the definition in RFC7270./* > > > I've opened an errata for that: > https://www.rfc-editor.org/errata/eid7775 > > */[Med] I don’ think an erratum applies here because the intent of > 7270 is clearly unsigned32:/* > > While you and I were working on NetFlow at Cisco when we wrote the RFC > 7270, I don't feel comfortable having an errata on a Cisco-specific IPFIX. > Anyway, what is the issue with keeping unsigned32, should we be > liberal in what we accept? > And we know that the reduced-size encoding > (https://datatracker.ietf.org/doc/html/rfc7011.html#section-6.2) will > be used anyway. It's not even useful to have this sentence (" > IPFIX reduced-size encoding is used as required") in the description > but I can live with it. > > Regards, Benoit > > > This email message and any attachments are confidential. If you are > not the intended recipient, please immediately reply to the sender and > delete the message from your email system. Thank you. _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg