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

Benoit Claise <benoit.claise@huawei.com> Tue, 06 February 2024 09:19 UTC

Return-Path: <benoit.claise@huawei.com>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74F98C14F6F2; Tue, 6 Feb 2024 01:19:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.984
X-Spam-Level:
X-Spam-Status: No, score=-1.984 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.091, 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_KAM_HTML_FONT_INVALID=0.01, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, 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 VTcX_kxJcaop; Tue, 6 Feb 2024 01:19:38 -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 C6D46C14F61A; Tue, 6 Feb 2024 01:19:37 -0800 (PST)
Received: from mail.maildlp.com (unknown [172.18.186.31]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4TTczx3Z5mz6JB3Q; Tue, 6 Feb 2024 17:15:57 +0800 (CST)
Received: from frapeml500001.china.huawei.com (unknown [7.182.85.94]) by mail.maildlp.com (Postfix) with ESMTPS id EFB47140C9C; Tue, 6 Feb 2024 17:19:33 +0800 (CST)
Received: from [10.45.152.118] (10.45.152.118) 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; Tue, 6 Feb 2024 10:19:24 +0100
Content-Type: multipart/alternative; boundary="------------uITqfCQ5Nk2SUGejihmrEqJ1"
Message-ID: <13e9edb0-33af-f2d7-fff2-fe1e0804cfa2@huawei.com>
Date: Tue, 06 Feb 2024 10:19:19 +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: Andrew Feren <andrew.feren=40plixer.com@dmarc.ietf.org>, "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, "Aitken, Paul" <paitken@ciena.com>, "Joe Clarke (jclarke)" <jclarke@cisco.com>, "opsawg@ietf.org" <opsawg@ietf.org>
CC: "tcpm@ietf.org" <tcpm@ietf.org>, "tsvwg@ietf.org" <tsvwg@ietf.org>, "6man@ietf.org" <6man@ietf.org>, "ipfix@ietf.org" <ipfix@ietf.org>
References: <BN9PR11MB53716555BC4D0F4FB8921408B890A@BN9PR11MB5371.namprd11.prod.outlook.com> <2d9602ce-6eb5-4667-b1c9-3db74590f352@ciena.com> <DU2PR02MB10160C3A2EC2AD4B08EA0C6D488742@DU2PR02MB10160.eurprd02.prod.outlook.com> <7da20efd-b7a2-44e7-9031-0f35b9ea837b@ciena.com> <DU2PR02MB101608C2847178159CA1C540E88742@DU2PR02MB10160.eurprd02.prod.outlook.com> <ca39adfb-2738-0d69-01ee-01437a6fd9f5@huawei.com> <SA3PR19MB8011E45ECEDA5FA9904CEC04F0472@SA3PR19MB8011.namprd19.prod.outlook.com>
From: Benoit Claise <benoit.claise@huawei.com>
In-Reply-To: <SA3PR19MB8011E45ECEDA5FA9904CEC04F0472@SA3PR19MB8011.namprd19.prod.outlook.com>
X-Originating-IP: [10.45.152.118]
X-ClientProxiedBy: dggems704-chm.china.huawei.com (10.3.19.181) To frapeml500001.china.huawei.com (7.182.85.94)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/FOsGEFLR84oMxX2Qfiw4XiWawcI>
Subject: Re: [tcpm] [IPFIX] errata eid7775 RE: [**EXTERNAL**] RE: WG LC: IPFIX documents
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Feb 2024 09:19:42 -0000

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.  Also CCO-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 <ipfix-bounces@ietf.org> on behalf of Benoit Claise 
> <benoit.claise=40huawei.com@dmarc.ietf.org>
> *Date: *Monday, February 5, 2024 at 12:37 PM
> *To: *mohamed.boucadair@orange.com <mohamed.boucadair@orange.com>, 
> Aitken, Paul <paitken@ciena.com>, Joe Clarke (jclarke) 
> <jclarke@cisco.com>, opsawg@ietf.org <opsawg@ietf.org>
> *Cc: *tcpm@ietf.org <tcpm@ietf.org>, tsvwg@ietf.org <tsvwg@ietf.org>, 
> 6man@ietf.org <6man@ietf.org>, ipfix@ietf.org <ipfix@ietf.org>
> *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, 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
>
>
> 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.