From warren@kumari.net Mon Apr 1 09:02:29 2024 Return-Path: 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 DAEA4C151545 for ; Mon, 1 Apr 2024 09:02:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=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 (2048-bit key) header.d=kumari.net 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 jjjma_9wkes0 for ; Mon, 1 Apr 2024 09:02:25 -0700 (PDT) Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 03223C151538 for ; Mon, 1 Apr 2024 09:02:24 -0700 (PDT) Received: by mail-ed1-x52d.google.com with SMTP id 4fb4d7f45d1cf-56c5d05128dso2652962a12.0 for ; Mon, 01 Apr 2024 09:02:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari.net; s=google; t=1711987343; x=1712592143; darn=ietf.org; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Gr+RI57GypHNg0GsGsUBAcioiSHqDfbBF58yA4lZ9fA=; b=f0EYdWdMG0isHpxwVHC76J+cUSPcZBBKY9x1n2XqDGYgROFUJ8JiZ30bErjdg2Z8+J VbeWFJgkRdzQNuj89vVkrIr7rBEtvDdEIljESHCivIxbYKYIhta44r0TFP9JEkcZnEYs qhgyCESQlL3ZdilkOBDa46D5wnnRQQTUIz8mVMd7e3EIRWtj4LSFX1DNiyQE9A94bXDu fINFuXpqZLpt78tYACJWyf8gO0vjwvIxhk5a85JXxdn6ZQnJ4VvFUIR+ltIptSfnf0aR FpmHblZJZ0clcqvUdGyZQF2yrDnmvpeb4DikmWb92kFjfFvO/ItDOx7xdsBsZTjUEQ9A Y2KQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711987343; x=1712592143; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Gr+RI57GypHNg0GsGsUBAcioiSHqDfbBF58yA4lZ9fA=; b=Uc/hqInhlXts97LToXg5OD+cJb9lkrE6ai29nenTHtH/SkGMFwEDJUkxcz9NSvd2pE qcKA1CPMN29v7cit/FBlz8ojgYtypKF0U56rRMthfhII081AzNzbP8Nd7ADYil6ZV7/W 7GctT8iv+z3IVyl6PGlqQ+rV5A9wjkk0WOBm7zbhaefgNaStmx4jJAOd/xFXjTJKgDuz CZVsC0nxFxNFtBZEb1NmiXXwlaAcB1/5lMUxlbTuCvdMVN9Xy4+4IwKAp0yM1c/h3Xs2 tAFDlNhiXvbtoQqKEmAnUhVnHs/f5qwCbXTxsr47kGEPX0G4PKlRccCjwX0AmsAm9Mq2 9+5A== X-Forwarded-Encrypted: i=1; AJvYcCWGLoVBBgXd30mK46Ae8ZaqeqOe2ZaVoPhQujD3y8LwhyjTQf2CY0yB0pXg842sYUAg45M/TkLImUFZ3xS3+A== X-Gm-Message-State: AOJu0Yx9U6khJeHK810fHuSFMH4B/B872zRu6pz8QhnH9epxMKpoxKVk C7L3JibKD7Fsa4xnZ0pEHqINc4/dwhBKsG2t0XlfiqX35PQuZY63HqyiQZtA+HJljlI+6q3dWBs HiR4Kzs+lcaZC9SeG4cQEn+AoKdogt4/HZt+1IA== X-Google-Smtp-Source: AGHT+IFvYffO9+ivsqkuPtKg+kj9feAcc7iaBnMwkelA3+4OHANR9tJz8tAX36Zvo77OUAD8HctgRhH7gHGRd9Ii4cQ= X-Received: by 2002:a05:6402:5212:b0:56b:9b4e:8838 with SMTP id s18-20020a056402521200b0056b9b4e8838mr7740131edd.0.1711987342628; Mon, 01 Apr 2024 09:02:22 -0700 (PDT) Received: from 649336022844 named unknown by gmailapi.google.com with HTTPREST; Mon, 1 Apr 2024 09:02:21 -0700 Mime-Version: 1.0 X-Superhuman-ID: luh51qkg.47844017-c45a-48c5-b51c-0c114b9c4f17 X-Superhuman-Draft-ID: draft00733a758a98ae2e X-Mailer: Superhuman Desktop (2024-03-29T19:06:23Z) In-Reply-To: <20240328191620.11E83191A4B4@rfcpa.amsl.com> References: <20240328191620.11E83191A4B4@rfcpa.amsl.com> From: Warren Kumari Date: Mon, 1 Apr 2024 09:02:21 -0700 Message-ID: To: RFC Errata System Cc: bclaise@cisco.com, trammell@tik.ee.ethz.ch, paitken@cisco.com, mjethanandani@gmail.com, n.brownlee@auckland.ac.nz, quittek@neclab.eu, prevost1@cert.org, ipfix@ietf.org Content-Type: multipart/alternative; boundary="0000000000006af11d06150b1dfd" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2024 16:02:29 -0000 --0000000000006af11d06150b1dfd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable [ - 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=E2=80=A6 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 > > -------------------------------------- > Type: Technical > Reported by: Katherine Prevost > > 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=E2=80=94and only non-nega= tive > values of signed integers have a representation that begins with zeroes. > > Either the text should clarify that negative values may never be expresse= d > 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 whic= h > 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 b= e > 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 th= e > 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 > > --0000000000006af11d06150b1dfd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
[ - Trammel@tik, +ietf@trammell.ch=C2=A0;=C2=A0 -Benoit@cisco, +=C2=A0benoit.claise@huawei.com=C2=A0]<= br>


Heyya.

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

Please let me know by the end = of the week=E2=80=A6

W

On Thu, Mar 28, 2024 at 3:= 16 PM, RFC Errata System <rfc-editor@rfc-edi= tor.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".

-------------------------------------- <= br>
You may review the report below and at:
https://www= .rfc-editor.org/errata/eid7875

--------------------------------------
Type: Technical
Reported by= : Katherine Prevost <prevost1@cert.org&= gt;

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 sugge= sts that integer values may only be encoded using a reduced-size encoding i= f they have a run of zeroes at the beginning. However, the specification al= so describes being able to use reduced-size encoding for signed integer val= ues=E2=80=94and only non-negative values of signed integers have a represen= tation that begins with zeroes.

Either the te= xt should clarify that negative values may never be expressed using a reduc= ed-size encoding (which is what the strictest reading of the current text w= ould suggest), or it should specify that leading ones may also be dropped f= or signed values, which makes it clear that they should be interpreted via = sign extension of the high bit.

A quick survey of exi= sting IPFIX implementations suggests that those which decode reduced-size e= ncoding of integers at all produce the semantic equivalent of sign extensio= n when they encounter a reduced-size encoding of a signed integer value.

Instructions:
-------------
This erratum is currently p= osted as "Reported". (If it is spam, it=20 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 =20 will log in to change the status and edit the report, if necessary.

--------------------------------= ------
RFC7011 (draft-ietf-ipfix-protocol-rfc510= 1bis-10)
-------------------------------------- =
Title : Specification of the IP Fl= ow 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


--0000000000006af11d06150b1dfd--