From benoit.claise@huawei.com Mon Feb 5 09:37:01 2024 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8AF1C14F68A; Mon, 5 Feb 2024 09:37:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.295 X-Spam-Level: X-Spam-Status: No, score=-4.295 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.091, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no 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 g6aKC3Jl4AFL; Mon, 5 Feb 2024 09:36:57 -0800 (PST) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F9EFC14F684; Mon, 5 Feb 2024 09:36:57 -0800 (PST) Received: from mail.maildlp.com (unknown [172.18.186.216]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4TTD4h4Nh3z6K998; Tue, 6 Feb 2024 01:33:40 +0800 (CST) Received: from frapeml500001.china.huawei.com (unknown [7.182.85.94]) by mail.maildlp.com (Postfix) with ESMTPS id 8C6F6140B73; Tue, 6 Feb 2024 01:36:54 +0800 (CST) Received: from [10.81.208.188] (10.81.208.188) by frapeml500001.china.huawei.com (7.182.85.94) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Mon, 5 Feb 2024 18:36:50 +0100 Content-Type: multipart/alternative; boundary="------------cWugtTvv0fLIL72con0Ve4f8" Message-ID: Date: Mon, 5 Feb 2024 18:36:45 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.15.1 Content-Language: en-US To: , "Aitken, Paul" , "Joe Clarke (jclarke)" , "opsawg@ietf.org" CC: "tcpm@ietf.org" , "tsvwg@ietf.org" , "6man@ietf.org" <6man@ietf.org>, "ipfix@ietf.org" References: <2d9602ce-6eb5-4667-b1c9-3db74590f352@ciena.com> <7da20efd-b7a2-44e7-9031-0f35b9ea837b@ciena.com> From: Benoit Claise In-Reply-To: X-Originating-IP: [10.81.208.188] X-ClientProxiedBy: dggems701-chm.china.huawei.com (10.3.19.178) To frapeml500001.china.huawei.com (7.182.85.94) Archived-At: Subject: Re: [OPSAWG] [IPFIX] errata eid7775 RE: [**EXTERNAL**] RE: WG LC: IPFIX documents X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Feb 2024 17:37:02 -0000 --------------cWugtTvv0fLIL72con0Ve4f8 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit Hi Paul, On 1/23/2024 12:14 PM, mohamed.boucadair@orange.com wrote: > >     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 --------------cWugtTvv0fLIL72con0Ve4f8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 8bit Hi Paul,

On 1/23/2024 12:14 PM, mohamed.boucadair@orange.com wrote:

    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



--------------cWugtTvv0fLIL72con0Ve4f8--