Hi all,
Bob is right here.
However, the intent of the original text is unambiguous as per the following:
==
Description
This Information Element describes the forwarding status of the
flow and any attached reasons. The reduced-size encoding rules as
per [RFC7011] apply.
The basic encoding is 8 bits. The future extensions
could add one or three bytes.
Abstract Data Type: unsigned32
==
Unless an extension is defined, unsigned8 will be used anyway following the
reduced-encoding in 7011.
Cheers,
Med
De : Bob Hinden <[email protected]>
Envoyé : mardi 6 février 2024 23:48
À : Benoit Claise <[email protected]>
Cc : Bob Hinden <[email protected]>; Andrew Feren <[email protected]>;
BOUCADAIR Mohamed INNOV/NET <[email protected]>; Aitken, Paul
<[email protected]>; Joe Clarke (jclarke) <[email protected]>; [email protected];
[email protected]; [email protected]; [email protected]; [email protected]
Objet : Re: [IPv6] [IPFIX] errata eid7775 RE: [**EXTERNAL**] RE: WG LC: IPFIX
documents
Benoit,
On Feb 6, 2024, at 1:12 PM, Benoit Claise
<[email protected]<mailto:[email protected]>> wrote:
Hi Bob,
On 2/6/2024 6:18 PM, Bob Hinden wrote:
Benoit,
To clarify, RFC7270 "Cisco-Specific Information Elements Reused in IP Flow
Information Export (IPFIX)” is a public RFC published for the Internet
Community. Cisco doesn’t have any specific change control over it.
Agreed, but they (Cisco) have to say whether this is an error or not, not the
community.
I would put it differently. Anyone can report an errata, the Area Directors
make the decision if the errata is accepted. That may including checking with
the authors. They do not check with the company where the authors worked at
the time the RFC was published.
Bob
Regards, Benoit
If there are known errors in it, they should be reported in an Errata. The ADs
who approve errata will take the correct action.
Bob
On Feb 6, 2024, at 1:19 AM, Benoit Claise
<[email protected]><mailto:[email protected]>
wrote:
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]><mailto:[email protected]> on behalf
of Benoit Claise
<[email protected]><mailto:[email protected]>
Date: Monday, February 5, 2024 at 12:37 PM
To: [email protected]<mailto:[email protected]>
<[email protected]><mailto:[email protected]>, Aitken,
Paul <[email protected]><mailto:[email protected]>, Joe Clarke (jclarke)
<[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]>,
[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]> <[email protected]><mailto:[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]<mailto:[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.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]<mailto:[email protected]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
____________________________________________________________________________________________________________
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.
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
