Re: [IPFIX] [Technical Errata Reported] RFC7011 (7875)

[Warren Kumari <[e-mail]>]

[ - Trammel@tik, [e-mail] ;  -Benoit@cisco, +
[e-mail]  (this time for real :-))]


Heyya.

I'm inclined to mark this as Verified, unless y'all think that that would
violate what the consensus was at the time?

Please let me know by the end of the week…

W


On Thu, Mar 28, 2024 at 3:16 PM, RFC Errata System <
[e-mail]> wrote:

> The following errata report has been submitted for RFC7011,
> "Specification of the IP Flow Information Export (IPFIX) Protocol for the
> Exchange of Flow Information".
>
> --------------------------------------
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid7875
>
> --------------------------------------
> Type: Technical
> Reported by: Katherine Prevost <[e-mail]>
>
> Section: 6.2
>
> Original Text
> -------------
> Reduced-size encoding MAY be applied to the following integer types:
> unsigned64, signed64, unsigned32, signed32, unsigned16, and signed16. The
> signed versus unsigned property of the reported value MUST be preserved.
> The reduction in size can be to any number of octets smaller than the
> original type if the data value still fits, i.e., so that only leading
> zeroes are dropped. For example, an unsigned64 can be reduced in size to 7,
> 6, 5, 4, 3, 2, or 1 octet(s).
>
> Corrected Text
> --------------
> Reduced-size encoding MAY be applied to the following integer types:
> unsigned64, signed64, unsigned32, signed32, unsigned16, and signed16. The
> signed versus unsigned property of the reported value MUST be preserved.
> The reduction in size can be to any number of octets smaller than the
> original type if the data value still fits, i.e., so that only leading
> zeroes are dropped. (Or, in the case of negative signed values, so that
> only leading ones are dropped.) For example, an unsigned64 can be reduced
> in size to 7, 6, 5, 4, 3, 2, or 1 octet(s).
>
> Notes
> -----
> As written, the specification suggests that integer values may only be
> encoded using a reduced-size encoding if they have a run of zeroes at the
> beginning. However, the specification also describes being able to use
> reduced-size encoding for signed integer values—and only non-negative
> values of signed integers have a representation that begins with zeroes.
>
> Either the text should clarify that negative values may never be expressed
> using a reduced-size encoding (which is what the strictest reading of the
> current text would suggest), or it should specify that leading ones may
> also be dropped for signed values, which makes it clear that they should be
> interpreted via sign extension of the high bit.
>
> A quick survey of existing IPFIX implementations suggests that those which
> decode reduced-size encoding of integers at all produce the semantic
> equivalent of sign extension when they encounter a reduced-size encoding of
> a signed integer value.
>
> Instructions:
> -------------
> This erratum is currently posted as "Reported". (If it is spam, it will be
> removed shortly by the RFC Production Center.) Please use "Reply All" to
> discuss whether it should be verified or rejected. When a decision is
> reached, the verifying party will log in to change the status and edit the
> report, if necessary.
>
> --------------------------------------
> RFC7011 (draft-ietf-ipfix-protocol-rfc5101bis-10)
> --------------------------------------
> Title : Specification of the IP Flow Information Export (IPFIX) Protocol
> for the Exchange of Flow Information Publication Date : September 2013
> Author(s) : B. Claise, Ed., B. Trammell, Ed., P. Aitken Category :
> INTERNET STANDARD
> Source : IP Flow Information Export
> Stream : IETF
> Verifying Party : IESG
>