[secdir] Re: Secdir last call review of draft-ietf-opsawg-ipfix-tcpo-v6eh-11
Benoit Claise <benoit.claise@huawei.com> Wed, 15 May 2024 16:31 UTC
Return-Path: <benoit.claise@huawei.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8DEEC14F6A4; Wed, 15 May 2024 09:31:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.139
X-Spam-Level:
X-Spam-Status: No, score=-6.139 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-1.944, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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
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 2kY8BSyeG7GC; Wed, 15 May 2024 09:31:34 -0700 (PDT)
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 D3E72C14F681; Wed, 15 May 2024 09:31:33 -0700 (PDT)
Received: from mail.maildlp.com (unknown [172.18.186.216]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4Vfdtz4pB0z6J9xb; Thu, 16 May 2024 00:28:11 +0800 (CST)
Received: from frapeml500001.china.huawei.com (unknown [7.182.85.94]) by mail.maildlp.com (Postfix) with ESMTPS id 1B47B140B35; Thu, 16 May 2024 00:31:32 +0800 (CST)
Received: from [10.126.173.232] (10.126.173.232) by frapeml500001.china.huawei.com (7.182.85.94) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.39; Wed, 15 May 2024 18:31:22 +0200
Message-ID: <b2cfa9ff-5354-3a19-3b65-c214400c2b96@huawei.com>
Date: Wed, 15 May 2024 18:31:13 +0200
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: Tero Kivinen <kivinen@iki.fi>, mohamed.boucadair@orange.com
References: <171526890711.64710.8472349123140714328@ietfa.amsl.com> <DU2PR02MB101607CD2621FF2E93D18AF6688E22@DU2PR02MB10160.eurprd02.prod.outlook.com> <26179.30124.656180.463251@fireball.acr.fi>
From: Benoit Claise <benoit.claise@huawei.com>
In-Reply-To: <26179.30124.656180.463251@fireball.acr.fi>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Originating-IP: [10.126.173.232]
X-ClientProxiedBy: dggems705-chm.china.huawei.com (10.3.19.182) To frapeml500001.china.huawei.com (7.182.85.94)
Message-ID-Hash: ASN7UC43DYO3KWPNVCEAH57F2GBTG24D
X-Message-ID-Hash: ASN7UC43DYO3KWPNVCEAH57F2GBTG24D
X-MailFrom: benoit.claise@huawei.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-secdir.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: "secdir@ietf.org" <secdir@ietf.org>, "draft-ietf-opsawg-ipfix-tcpo-v6eh.all@ietf.org" <draft-ietf-opsawg-ipfix-tcpo-v6eh.all@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>, "opsawg@ietf.org" <opsawg@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [secdir] Re: Secdir last call review of draft-ietf-opsawg-ipfix-tcpo-v6eh-11
List-Id: Security Area Directorate <secdir.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/IWyxEz9wuJNMeE71aP0851UU7MM>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Owner: <mailto:secdir-owner@ietf.org>
List-Post: <mailto:secdir@ietf.org>
List-Subscribe: <mailto:secdir-join@ietf.org>
List-Unsubscribe: <mailto:secdir-leave@ietf.org>
Tero, We could potentially ask the RFC-editors to do this task? Or maybe they do it automatically? Regards, Benoit On 5/14/2024 4:31 PM, Tero Kivinen wrote: > mohamed.boucadair@orange.com writes: >>> In section 8.3 change >>> >>> This type MUST be encoded per >>> Section 6.1.1 of [RFC7011]. Reduced-Size encoding (Section >>> 6.2 of >>> [RFC7011]) applies to this data type. >>> >>> to >>> >>> This type MUST be encoded per >>> Section 6.1.1 of IPFIX specification [RFC7011]. Reduced-Size >>> encoding (Section 6.2 of IPFIX specification [RFC7011]) >>> applies to >>> this data type. >>> >>> -- >> [Med] This is a matter of editing taste. I'm not fun of expanding >> the ref title. > I think it is important for lowering the bar to getting people > involved in the IETF protocols. If you need to learn mapping of > tens or hundreds of rfc numbers to the actual titles, before you can > easily read documents it makes it much harder to read the document, > and causes extra work for the reader. > > Expanding it by the author once, will save that mapping to be done by > people who read it. There are RFCs where there is less readers than > writers, but I hope that is exception not a norm. > > When I was reviewing that draft, I had to google the RFC numbers > multiple times (even the same ones) just to make sure which one is > which. > > Also it is bad form of using reference as a noun. It makes [1] to [2] > text when some of the [3] is not near the part using it. > > [1] https://dictionary.cambridge.org/dictionary/english/difficult > [2] https://dictionary.cambridge.org/dictionary/english/read > [3] https://dictionary.cambridge.org/dictionary/english/text > >>> Section 9.1 [IANA-EH] url is wrong, it points to the "Next Header >>> Types" registry, not to the "IPv6 Extension Header Types" >>> registry. >> [Med] This is on purpose because the RFC Editor does not cite the specific URLs, only the URL of the registry group. >> >>> Correct url is >>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2 >>> Fwww.iana.org%2Fassignments%2Fipv6-parameters%2Fipv6- >>> parameters.xhtml%23extension- >>> header&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Ce04d445565 >>> be47dc729308dc703d9ca0%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0 >>> %7C638508657119400747%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDA >>> iLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdat >>> a=sAElkvoUqJFN0K5eFgX%2F73LEbbqAWqerHq0IDzQsy%2Bo%3D&reserved=0 > The link I provided pointed directly to the registry you referenced > to. If yo go to the registry itself the beginning of it has table of > contents, which provides links to exact registries.
- [secdir] Secdir last call review of draft-ietf-op… Tero Kivinen via Datatracker
- [secdir] Re: Secdir last call review of draft-iet… Tero Kivinen
- [secdir] Re: Secdir last call review of draft-iet… Benoit Claise
- [secdir] Re: Secdir last call review of draft-iet… mohamed.boucadair
- [secdir] Re: Secdir last call review of draft-iet… Tero Kivinen