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