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

"Brian Trammell (IETF)" <ietf@trammell.ch> Tue, 02 April 2024 04:30 UTC

Return-Path: <ietf@trammell.ch>
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC7E5C14F694 for <ipfix@ietfa.amsl.com>; Mon, 1 Apr 2024 21:30:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.205
X-Spam-Level:
X-Spam-Status: No, score=-6.205 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, MIME_HTML_ONLY_MULTI=0.001, MIME_QP_LONG_LINE=0.001, MPART_ALT_DIFF=0.79, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=trammell.ch
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Qpw_YDqdWiV for <ipfix@ietfa.amsl.com>; Mon, 1 Apr 2024 21:30:33 -0700 (PDT)
Received: from smtp-bc0f.mail.infomaniak.ch (smtp-bc0f.mail.infomaniak.ch [IPv6:2001:1600:7:10::bc0f]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5405C151087 for <ipfix@ietf.org>; Mon, 1 Apr 2024 21:30:31 -0700 (PDT)
Received: from smtp-4-0001.mail.infomaniak.ch (smtp-4-0001.mail.infomaniak.ch [10.7.10.108]) by smtp-4-3000.mail.infomaniak.ch (Postfix) with ESMTPS id 4V7w0j1LlHzQ1R; Tue, 2 Apr 2024 06:30:29 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=trammell.ch; s=20191114; t=1712032229; bh=3t5oAvXaJReyET9hMpz5WJ1WtZLZI7m0sjMSWF0pDVM=; h=From:Subject:Date:References:Cc:In-Reply-To:To:From; b=lbGp7M00+teaYhz1xYpWSj2JjuN03YUvQApcj1grIcgKbC03DffWCoHn6jLQCnoTq TLYV3Ls3OCgs72GzKYVqsHAjK0txuIBvLebCOjz9/IrrVlczJQQZmKXo7JX6i4O4aH yRvlf4UUd476hwJt/Y4uVqa9esnGZwfzMEnQ+6xU=
Received: from unknown by smtp-4-0001.mail.infomaniak.ch (Postfix) with ESMTPA id 4V7w0g4JRrzjqp; Tue, 2 Apr 2024 06:30:27 +0200 (CEST)
Content-Type: multipart/alternative; boundary="Apple-Mail-79D214A5-2E7D-48D5-BC0A-F4F9500B70BE"
Content-Transfer-Encoding: 7bit
From: "Brian Trammell (IETF)" <ietf@trammell.ch>
Mime-Version: 1.0 (1.0)
Date: Tue, 02 Apr 2024 06:30:17 +0200
Message-Id: <B197E164-C330-4D25-A97B-5B5F3719C6B6@trammell.ch>
References: <CAHw9_iJ5gzqjkOyddwmhCvQ0zpVzOJif6SsWqU0Q4XYzCVhVOw@mail.gmail.com>
Cc: RFC Errata System <rfc-editor@rfc-editor.org>, paitken@cisco.com, ipfix@ietf.org, prevost1@cert.org, mjethanandani@gmail.com, n.brownlee@auckland.ac.nz, bclaise@cisco.com, trammell@tik.ee.ethz.ch
In-Reply-To: <CAHw9_iJ5gzqjkOyddwmhCvQ0zpVzOJif6SsWqU0Q4XYzCVhVOw@mail.gmail.com>
To: Warren Kumari <warren@kumari.net>
X-Mailer: iPhone Mail (21E236)
X-Infomaniak-Routing: alpha
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipfix/FbS4n9-EymFhUFngFgs8fGTeBbE>
Subject: Re: [IPFIX] [Technical Errata Reported] RFC7011 (7875)
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IPFIX WG discussion list <ipfix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipfix>, <mailto:ipfix-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipfix/>
List-Post: <mailto:ipfix@ietf.org>
List-Help: <mailto:ipfix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipfix>, <mailto:ipfix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Apr 2024 04:30:37 -0000

Yep, this one can be verified.

Sent from my iPhone

On 1 Apr 2024, at 18:02, Warren Kumari <warren@kumari.net> wrote:


[ - Trammel@tik, +ietf@trammell.ch ;  -Benoit@cisco, + benoit.claise@huawei.com ]


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 <rfc-editor@rfc-editor.org> 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" class="">https://www.rfc-editor.org/errata/eid7875

--------------------------------------
Type: Technical
Reported by: Katherine Prevost <prevost1@cert.org>

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


_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www.ietf.org/mailman/listinfo/ipfix