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

Bob Hinden <bob.hinden@gmail.com> Tue, 06 February 2024 22:48 UTC

Return-Path: <bob.hinden@gmail.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 481BDC14F748; Tue, 6 Feb 2024 14:48:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.104
X-Spam-Level:
X-Spam-Status: No, score=-2.104 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=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_BLOCKED=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=gmail.com
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 zrujBjxnUTAf; Tue, 6 Feb 2024 14:48:26 -0800 (PST)
Received: from mail-yb1-xb29.google.com (mail-yb1-xb29.google.com [IPv6:2607:f8b0:4864:20::b29]) (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 C7A1AC151076; Tue, 6 Feb 2024 14:48:26 -0800 (PST)
Received: by mail-yb1-xb29.google.com with SMTP id 3f1490d57ef6-dc6e4a55a71so4639689276.3; Tue, 06 Feb 2024 14:48:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1707259706; x=1707864506; darn=ietf.org; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=AIpOxdXCDHIjtzih44Y5JvNYclzRveDn6zP3SRAw9us=; b=nqt0n4sufaz+up85bTxQUU+hCVgXV/dSH/eKDNyu4F6ViqbfEh6ykD1c9ojr+LbFBy ZmpNj7KNC/5hIiNm7mz1vpsnw1cm8FA0QdxupxDloXw39rbYvJnJQBknOuEVc6FuZBr/ e+X8wyAkvhFl01OVd+kzt0decpwJpeQBJxptmiUtK7uk8h2j0/w/A/2pFdI/pteXcn+9 M1JCEcM5B8NBQR3CbOvntKvZv2MFSV/La5My8WjyulyXHFIPycZGWy77Tsw8/r9fYUSS DhTR7mYBBtHHAKP7qXFXm5S7NS7YvjmIeDd3MBOdERoW4BtoEmNcCTpwwsggxpBCeKKP 0ALA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707259706; x=1707864506; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=AIpOxdXCDHIjtzih44Y5JvNYclzRveDn6zP3SRAw9us=; b=ne2xhMGBKouvGY6iMBYuYNHvMOZS2tdMNDz5dN7gZhPT/EVJMQuT8AdhgjP1vZadRc t3F+l3zgBdXxCY5IRYdTpBxQOnyhGlL5jEDoYXlgo/0Hf0n729HqCt+gbmNGCbdUDAbD k+u2Ic88cfwOaKkN2abm1b/pEvWN+en1kcpR6+6JPW/AA+kg7RzAJ3MnNIqG9EIb14ty +PKjeCD/J7D7iFgbR3uiO9f3Tmf5L5xr0Uel3BXXU0tl/wcmkqr72BoGKBZLK8MjMxtr klB+IFB3+9riE/o+qjWmHJam8se0lRLpkviZ+jpb1T4+UBpB/gukXiXQJrm1KuuqNsXa Cmjg==
X-Forwarded-Encrypted: i=1; AJvYcCXGU5IJoh8dpsIUB0W3QST18ygg+R3XI15SBnfwvr+iqiIKTjSUJ6wx8UIhQlbjK62UDFQEspAfT2xsh/5khK+BkjTKruuNFIpFJmAjB2/3FGHdQOqQ+Bt4dv38w/RvDuKOaAZihBAyMANdLtfzmJHT40g18IwMH9y2ak7yZg==
X-Gm-Message-State: AOJu0YwqOsxx/qV9MzVIIRVY86kj4w3qN4lYGa53ZVKVhMCfEUYQAX4L A+Cx0ZGDHenbJz6bD9e6YEawsj5Pf6AewoNlhUuj54+4gmWjPDyA
X-Google-Smtp-Source: AGHT+IH8W/mhucSzmgwPAUo2hpT4IhIiYN8FrsS6lmCEXSsBquLBiryDcfoXLAOyjAXjBgOTfGS7Gg==
X-Received: by 2002:a05:6902:120b:b0:dc6:9e21:9079 with SMTP id s11-20020a056902120b00b00dc69e219079mr3233062ybu.45.1707259705781; Tue, 06 Feb 2024 14:48:25 -0800 (PST)
X-Forwarded-Encrypted: i=0; AJvYcCVPUZ/wHW6SA8q0KLZip3Mhy1GoEvRcX5He5sA30itMqpJyszRpBp9DCTadVZ9jfL3YjFj49GfzPVtLY224pr7GPImxKxxcD8+3+NSa/+zZpD4piRngYcXyq2mqvqBflhX1HTyPEssQXVNe28VpYSRmEe90GDw5osg8mOpqAW2fExg9KxHZFemjnMU5k24UQUjx3mcB81BXBu/ZWG7WSGCAuHYj4j8d2ueYXL9UDGQPzTTV1SdnP/OR+KVzwtnX1myyvWGQzJu4XxfzNm500puupTTSkSCW6W7MsQ==
Received: from smtpclient.apple (99-31-208-116.lightspeed.sntcca.sbcglobal.net. [99.31.208.116]) by smtp.gmail.com with ESMTPSA id n203-20020a25d6d4000000b00d677aec54ffsm696286ybg.60.2024.02.06.14.48.24 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Feb 2024 14:48:25 -0800 (PST)
From: Bob Hinden <bob.hinden@gmail.com>
Message-Id: <5A996FAF-D71B-4CAD-BC0C-6216A918B410@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_1FF98823-A201-403B-84CE-F43D9227939F"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.400.31\))
Date: Tue, 06 Feb 2024 14:48:03 -0800
In-Reply-To: <f3bad7b7-3d7b-c2d6-80d6-dde578d3c0fc@huawei.com>
Cc: Bob Hinden <bob.hinden@gmail.com>, Andrew Feren <andrew.feren@plixer.com>, "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>, "tcpm@ietf.org" <tcpm@ietf.org>, "tsvwg@ietf.org" <tsvwg@ietf.org>, "6man@ietf.org" <6man@ietf.org>, "ipfix@ietf.org" <ipfix@ietf.org>
To: Benoit Claise <benoit.claise@huawei.com>
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> <13e9edb0-33af-f2d7-fff2-fe1e0804cfa2@huawei.com> <349F35FB-EA76-42BA-A409-6690D3180FAB@gmail.com> <f3bad7b7-3d7b-c2d6-80d6-dde578d3c0fc@huawei.com>
X-Mailer: Apple Mail (2.3774.400.31)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/7_GOf1JJ5sk6JaoqViY-29sIPmA>
X-Mailman-Approved-At: Wed, 07 Feb 2024 09:06:16 -0800
Subject: Re: [tcpm] [IPv6] [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 22:48:31 -0000

Benoit,

> On Feb 6, 2024, at 1:12 PM, Benoit Claise <benoit.claise@huawei.com> wrote:
> 
> Hi Bob,
> 
> On 2/6/2024 6:18 PM, Bob Hinden wrote:
>> Benoit,
>> 
>> To clarify, RFC7270  "Cisco-Specific Information Elements  Reused in IP Flow Information Export (IPFIX)” is a public RFC published for the Internet Community.   Cisco doesn’t have any specific change control over it.
> Agreed, but they (Cisco) have to say whether this is an error or not, not the community.

I would put it differently.    Anyone can report an errata, the Area Directors make the decision if the errata is accepted.   That may including checking with the authors.   They do not check with the company where the authors worked at the time the RFC was published.

Bob



> 
> Regards, Benoit
>> 
>> If there are known errors in it, they should be reported in an Errata.  The ADs who approve errata will take the correct action.
>> 
>> Bob
>> 
>> 
>>> On Feb 6, 2024, at 1:19 AM, Benoit Claise <benoit.claise=40huawei.com@dmarc.ietf.org> <mailto:benoit.claise=40huawei.com@dmarc.ietf.org> wrote:
>>> 
>>> 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> <mailto:ipfix-bounces@ietf.org> on behalf of Benoit Claise <benoit.claise=40huawei.com@dmarc.ietf.org> <mailto:benoit.claise=40huawei.com@dmarc.ietf.org>
>>>> Date: Monday, February 5, 2024 at 12:37 PM
>>>> To: mohamed.boucadair@orange.com <mailto:mohamed.boucadair@orange.com> <mohamed.boucadair@orange.com> <mailto:mohamed.boucadair@orange.com>, Aitken, Paul <paitken@ciena.com> <mailto:paitken@ciena.com>, Joe Clarke (jclarke) <jclarke@cisco.com> <mailto:jclarke@cisco.com>, opsawg@ietf.org <mailto:opsawg@ietf.org> <opsawg@ietf.org> <mailto:opsawg@ietf.org>
>>>> Cc: tcpm@ietf.org <mailto:tcpm@ietf.org> <tcpm@ietf.org> <mailto:tcpm@ietf.org>, tsvwg@ietf.org <mailto:tsvwg@ietf.org> <tsvwg@ietf.org> <mailto:tsvwg@ietf.org>, 6man@ietf.org <mailto:6man@ietf.org> <6man@ietf.org> <mailto:6man@ietf.org>, ipfix@ietf.org <mailto:ipfix@ietf.org> <ipfix@ietf.org> <mailto: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 <mailto: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.
>>> 
>>> --------------------------------------------------------------------
>>> IETF IPv6 working group mailing list
>>> ipv6@ietf.org <mailto:ipv6@ietf.org>
>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------
>> 
>