From bob.hinden@gmail.com Tue Feb 6 09:18:37 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 61DF3C14F73F; Tue, 6 Feb 2024 09:18:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.104 X-Spam-Level: X-Spam-Status: No, score=-7.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_DNSWL_HI=-5, 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=unavailable 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 LJlC8pHEeV98; Tue, 6 Feb 2024 09:18:32 -0800 (PST) Received: from mail-oo1-xc33.google.com (mail-oo1-xc33.google.com [IPv6:2607:f8b0:4864:20::c33]) (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 736CCC14F5F8; Tue, 6 Feb 2024 09:18:27 -0800 (PST) Received: by mail-oo1-xc33.google.com with SMTP id 006d021491bc7-59a99ef8c7fso2419595eaf.0; Tue, 06 Feb 2024 09:18:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1707239906; x=1707844706; 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=1PT8odShz8lSucGn5P9x5z7KcNof6ZvLKlZMJzR/VtM=; b=fruozDTqT+ZGtRDnCLO+oiO/SQRVfQ3o/1qNrkHVJygLj+T/z91PW2eJyYekXyb3qa g6AcaZmyFHnsQFGxtQ+3iwlv1eUxCk9so0R1hzuKuzJC30OXajah0icHMoYUf1ZShHJu 1MtrSp/nbATwujoVwBKrINQ8b705qEdP9fwahPlB60AVpWNGgW4gkHnpDuUajTVh9raz 4a0u/8z/dNG9hUxbB1DVFta8PcVs7hi6Fc3KGle5hYhHaj+0BtPE/20xXIHiLwvWBY8z cIK4TsSbIznvxE31yO3sPmtrZSBXmI3bg//TDPdfDWHEn3ni3iWPSqdn15JnuPWjPYGN DVyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707239906; x=1707844706; 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=1PT8odShz8lSucGn5P9x5z7KcNof6ZvLKlZMJzR/VtM=; b=F+jok7wUvPGIHBhnP11usOq9OynFNmkCd8wTPCqol8uBzopBPn3lFOkalBoiUfOg/I 8zbLFGhHNiDZVGEr3LGiH8hJsVehbcrCv9feFxpmGVSKDBjm1Mw6AYDEiVtNRuWVqb5U 5nXvcttmdU/0eDN4axYHno4CodrtMTbFShvQlVQ6BB7JVyQznR842eHQL0J3zoCPNkFZ Mb0XcbDZ+QSW6mLZGJvEoWLxTCaPyQ0tfUcPSS1Ixrjj6/9KrmNj1fjQuHmmmrqiqvKo fs4MWGLtUhP3a5jPW23n08LppK1RwNZq3RlbajPNMxZJyRzUGI6dFTOX5PFHGtUhin9D 3v+A== X-Gm-Message-State: AOJu0Yw8qKOSWEkrbcvwwUEoWm6NxduEyTCwlcHHYSUzBRwmaQnJ4cyt Oaw0HymUeNR9gdWVUU6SPw40VM2O3va//XjVfucmDNr32zmRUssT X-Google-Smtp-Source: AGHT+IHx6Ik3KPlF+nJZ7MHF1IBHLYmD/LRKbmynnVDeJ+1lBclgvpR5uCChv51N9juQbUbS+i6Fkg== X-Received: by 2002:a05:6358:7e10:b0:176:80c4:a44b with SMTP id o16-20020a0563587e1000b0017680c4a44bmr166471rwm.9.1707239906001; Tue, 06 Feb 2024 09:18:26 -0800 (PST) X-Forwarded-Encrypted: i=0; AJvYcCXI0BxwFujskP+6gp5n3jTi8DQryCEhmSvAp9F2SNiPBOsbk8RWDeeL4jEKWdPg8xwjarhZ8IyqAsaDPA6wV0v8oVP5YAcEZzqDmfQRnpq29dzZyHZ+i5EA4ShD6lUCwKmN9Zdk5YMDFws/wXMoZp62AiX2iMphRgFOYN9RZyOwGvtZ8DtFqryi7YazyC8fSiRVKSzOjMIsJNkt6duhUfQV7s9VtTTOQkOGvoEaISMgY7UgYW4t/A5Oh0ZN3xjOhcMJJOzVJPpLkkHQfCaWv+5XENACk6i/atiRHEQSdSr1FgBcKyEp8XJIL/gP Received: from smtpclient.apple (99-31-208-116.lightspeed.sntcca.sbcglobal.net. [99.31.208.116]) by smtp.gmail.com with ESMTPSA id ez9-20020a05690c308900b006040e1502fbsm553908ywb.13.2024.02.06.09.18.24 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Feb 2024 09:18:25 -0800 (PST) From: Bob Hinden Message-Id: <349F35FB-EA76-42BA-A409-6690D3180FAB@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_C341FEB9-C34D-480C-A6EE-9C326C44A4EA" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.400.31\)) Date: Tue, 6 Feb 2024 09:18:03 -0800 In-Reply-To: <13e9edb0-33af-f2d7-fff2-fe1e0804cfa2@huawei.com> Cc: Bob Hinden , Andrew Feren , "mohamed.boucadair@orange.com" , "Aitken, Paul" , "Joe Clarke (jclarke)" , "opsawg@ietf.org" , "tcpm@ietf.org" , "tsvwg@ietf.org" , "6man@ietf.org" <6man@ietf.org>, "ipfix@ietf.org" To: Benoit Claise References: <2d9602ce-6eb5-4667-b1c9-3db74590f352@ciena.com> <7da20efd-b7a2-44e7-9031-0f35b9ea837b@ciena.com> <13e9edb0-33af-f2d7-fff2-fe1e0804cfa2@huawei.com> X-Mailer: Apple Mail (2.3774.400.31) Archived-At: Subject: Re: [IPFIX] [IPv6] errata eid7775 RE: [**EXTERNAL**] RE: WG LC: IPFIX documents 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: Tue, 06 Feb 2024 17:18:37 -0000 --Apple-Mail=_C341FEB9-C34D-480C-A6EE-9C326C44A4EA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Benoit, To clarify, RFC7270 "Cisco-Specific Information Elements Reused in IP = Flow Information Export (IPFIX)=E2=80=9D is a public RFC published for = the Internet Community. Cisco doesn=E2=80=99t have any specific change = control over it. 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=E2=80=AFAM, Benoit Claise = wrote: >=20 > Hi Andrew, >=20 > 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". >=20 > Regards, Benoit >=20 > On 2/5/2024 7:12 PM, Andrew Feren wrote: >> Hi Benoit, >> =20 >> I see your point about not having an errata on a Cisco RFC. That = being said=E2=80=A6. >> =20 >> It appears that the IANA page has listed forwardingStatus(89) as = unsigned8 since 2018. Also CCO-NF9FMT = , the other cisco document referenced for = forwardingStatus(89), is pretty unambiguous that forwardingStatus(89) is = 1 byte. Beyond that I don=E2=80=99t 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. >> =20 >> -Andrew >> =20 >> From: IPFIX = on behalf of Benoit Claise = >> Date: Monday, February 5, 2024 at 12:37=E2=80=AFPM >> To: mohamed.boucadair@orange.com = = , Aitken, Paul = , Joe Clarke (jclarke) = , opsawg@ietf.org = >> Cc: tcpm@ietf.org = , tsvwg@ietf.org = , 6man@ietf.org = <6man@ietf.org> , = ipfix@ietf.org = >> Subject: Re: [IPFIX] errata eid7775 RE: [**EXTERNAL**] RE: WG LC: = IPFIX documents >>=20 >> [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. >> =20 >> Hi Paul, >>=20 >> On 1/23/2024 12:14 PM, mohamed.boucadair@orange.com = wrote: >> 4.3. forwardingStatus >>=20 >> In particular, the registered Abstract >> Data Type is unsigned8, while it must be unsigned32. >>=20 >> Why must it be? >> [Med] As per the definition in RFC7270. >>=20 >> I've opened an errata for that: = https://www.rfc-editor.org/errata/eid7775 >> [Med] I don=E2=80=99 think an erratum applies here because the intent = of 7270 is clearly unsigned32: >> =20 >> 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. >>=20 >> Regards, Benoit >>=20 >>=20 >>=20 >> 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. >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --Apple-Mail=_C341FEB9-C34D-480C-A6EE-9C326C44A4EA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Benoit,

To clarify, RFC7270 =  "Cisco-Specific Information Elements  Reused in IP Flow = Information Export (IPFIX)=E2=80=9D is a public RFC published for the = Internet Community.   Cisco doesn=E2=80=99t have any specific = change control over it.

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=E2=80=AFAM, Benoit = Claise <benoit.claise=3D40huawei.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=E2=80=A6.
 
It appears that the IANA page has listed = forwardingStatus(89) as unsigned8 since 2018.  Also CCO-NF9FMT, the other cisco = document referenced for forwardingStatus(89), is pretty unambiguous that = forwardingStatus(89) is 1 byte.  Beyond that I don=E2=80=99t 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=3D40huawei.com@dmarc.ietf.org>
= Date: Monday, = February 5, 2024 at 12:37=E2=80=AFPM
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=E2=80=99 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
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
-------------------------------------------------------------= -------

= --Apple-Mail=_C341FEB9-C34D-480C-A6EE-9C326C44A4EA--