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

[Benoit Claise <[e-mail]>]

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=[e-mail]> 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<[e-mail]>on behalf of Benoit 
>>> Claise<benoit.claise=[e-mail]>
>>> *Date:*Monday, February 5, 2024 at 12:37 PM
>>> *To:*[e-mail]<[e-mail]>, 
>>> Aitken, Paul<[e-mail]>, Joe Clarke 
>>> (jclarke)<[e-mail]>,[e-mail]<[e-mail]>
>>> *Cc:*[e-mail]<[e-mail]>,[e-mail]<[e-mail]>,[e-mail]<[e-mail]>,[e-mail]<[e-mail]>
>>> *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,[e-mail]:
>>>
>>>             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
>> [e-mail]
>> Administrative Requests:https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>