Re: [OPSAWG] [IPFIX] errata eid7775 RE: [**EXTERNAL**] RE: WG LC: IPFIX documents

2024-02-06 Thread Benoit Claise 

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 
, 
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  on behalf of Benoit Claise 


*Date: *Monday, February 5, 2024 at 12:37 PM
*To: *mohamed.boucad...@orange.com , 
Aitken, Paul , Joe Clarke (jclarke) 
, opsawg@ietf.org 
*Cc: *t...@ietf.org , ts...@ietf.org , 
6...@ietf.org <6...@ietf.org>, ip...@ietf.org 
*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, mohamed.boucad...@orange.com 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
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] [IPFIX] errata eid7775 RE: [**EXTERNAL**] RE: WG LC: IPFIX documents

2024-02-05 Thread Andrew Feren 
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,
 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  on behalf of Benoit Claise 

Date: Monday, February 5, 2024 at 12:37 PM
To: mohamed.boucad...@orange.com , Aitken, Paul 
, Joe Clarke (jclarke) , opsawg@ietf.org 

Cc: t...@ietf.org , ts...@ietf.org , 
6...@ietf.org <6...@ietf.org>, ip...@ietf.org 
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, 
mohamed.boucad...@orange.com 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
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] [IPFIX] errata eid7775 RE: [**EXTERNAL**] RE: WG LC: IPFIX documents

2024-02-05 Thread Benoit Claise 

Hi Paul,

On 1/23/2024 12:14 PM, mohamed.boucad...@orange.com 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


___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg