Re: [secdir] [Last-Call] Secdir last call review of draft-ietf-alto-unified-props-new-18

Qin Wu <bill.wu@huawei.com> Wed, 20 October 2021 02:04 UTC

Return-Path: <bill.wu@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 637063A048A; Tue, 19 Oct 2021 19:04:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.197
X-Spam-Level:
X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YLNcnMgNe_55; Tue, 19 Oct 2021 19:04:26 -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 E414D3A040A; Tue, 19 Oct 2021 19:04:25 -0700 (PDT)
Received: from fraeml735-chm.china.huawei.com (unknown [172.18.147.206]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4HYv3f0rRxz67yJR; Wed, 20 Oct 2021 10:01:18 +0800 (CST)
Received: from dggeml702-chm.china.huawei.com (10.3.17.135) by fraeml735-chm.china.huawei.com (10.206.15.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.2308.15; Wed, 20 Oct 2021 04:04:21 +0200
Received: from dggeml753-chm.china.huawei.com (10.1.199.152) by dggeml702-chm.china.huawei.com (10.3.17.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2308.15; Wed, 20 Oct 2021 10:04:19 +0800
Received: from dggeml753-chm.china.huawei.com ([10.1.199.152]) by dggeml753-chm.china.huawei.com ([10.1.199.152]) with mapi id 15.01.2308.015; Wed, 20 Oct 2021 10:04:19 +0800
From: Qin Wu <bill.wu@huawei.com>
To: Paul Wouters <paul.wouters@aiven.io>, "Randriamasy, Sabine (Nokia - FR/Paris-Saclay)" <sabine.randriamasy@nokia-bell-labs.com>
CC: "secdir@ietf.org" <secdir@ietf.org>, "draft-ietf-alto-unified-props-new.all@ietf.org" <draft-ietf-alto-unified-props-new.all@ietf.org>, "alto@ietf.org" <alto@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>
Thread-Topic: [Last-Call] Secdir last call review of draft-ietf-alto-unified-props-new-18
Thread-Index: AdfFVnpo4uclBceW0kW1LdMhbWJK7A==
Date: Wed, 20 Oct 2021 02:04:19 +0000
Message-ID: <afeba8bb4c654c81900b74eff9b5419f@huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.136.123.117]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/hNB38kffmA31UHRbduc-yLAlscU>
Subject: Re: [secdir] [Last-Call] Secdir last call review of draft-ietf-alto-unified-props-new-18
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Oct 2021 02:04:32 -0000

>> While extensions to a protocol don't necessitate an Updates: clause, 
>> in this case I think it should because the document addresses 
>> shortcomings in the original protocol. That is, new implementations 
>> are expected to really require implementing this new document as part 
>> of the "core specification". Thus implementers reading 7285 should 
>> really be warned to also read (and
>> implement) this document.
>
> [ [SR] ] we do not oppose entities against endpoints therefore this 
> extension does not intend to replace endpoints by entities. Both are 
> useful, as some use cases can live with the base protocol. A 
> discussion thread has just started on this point and we will like to 
> have your conclusions on the exposed points of view

An RFC update does not mean "do not implement what was in the older one". Update really means that one should read (and ideally implement) both documents to get the updated picture of what the IETF believes should be implemented. If this is just an optional extension, then Update: is not needed. But if it modifies the previous document to clarify or extend in a way that is core to the protocol, it should probably Update: the previous RFC so implementers know there is more to take into account than just that core older document.

[Qin Wu] Thank Paul for comment on this issue, ALTO WG has revisited issues again and the conclusion we made is this draft just focuses on an optional extension, a few explanation text will be added into abstract to clarify why update tag is not needed and confusion words will be cleaned up.
https://mailarchive.ietf.org/arch/msg/alto/ykK66Uv_ypbsh9mn9SPu0QL01-k/