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.
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
<benoit.claise=40huawei....@dmarc.ietf.org> 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. AlsoCCO-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<ipfix-boun...@ietf.org>on behalf of Benoit
Claise<benoit.claise=40huawei....@dmarc.ietf.org>
*Date:*Monday, February 5, 2024 at 12:37 PM
*To:*mohamed.boucad...@orange.com<mohamed.boucad...@orange.com>,
Aitken, Paul<pait...@ciena.com>, Joe Clarke
(jclarke)<jcla...@cisco.com>,opsawg@ietf.org<opsawg@ietf.org>
*Cc:*t...@ietf.org<t...@ietf.org>,ts...@ietf.org<ts...@ietf.org>,6...@ietf.org<6...@ietf.org>,ip...@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.boucadair@orange.comwrote:
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
i...@ietf.org
Administrative Requests:https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg