Re: [ippm] Roman Danyliw's No Objection on draft-ietf-ippm-ioam-yang-11: (with COMMENT)
Tianran Zhou <zhoutianran@huawei.com> Tue, 27 February 2024 07:02 UTC
Return-Path: <zhoutianran@huawei.com>
X-Original-To: ippm@ietfa.amsl.com
Delivered-To: ippm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20172C14F6FE; Mon, 26 Feb 2024 23:02:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.904
X-Spam-Level:
X-Spam-Status: No, score=-1.904 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=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_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 qOoEeZ9wCYpb; Mon, 26 Feb 2024 23:02:05 -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 1EF01C14F697; Mon, 26 Feb 2024 23:02:05 -0800 (PST)
Received: from mail.maildlp.com (unknown [172.18.186.216]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4TkSwk3695z6K5qK; Tue, 27 Feb 2024 14:57:42 +0800 (CST)
Received: from lhrpeml100004.china.huawei.com (unknown [7.191.162.219]) by mail.maildlp.com (Postfix) with ESMTPS id 631B91400CD; Tue, 27 Feb 2024 15:01:43 +0800 (CST)
Received: from dggpemm100005.china.huawei.com (7.185.36.231) by lhrpeml100004.china.huawei.com (7.191.162.219) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.35; Tue, 27 Feb 2024 07:01:42 +0000
Received: from kwepemd100004.china.huawei.com (7.221.188.31) by dggpemm100005.china.huawei.com (7.185.36.231) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.35; Tue, 27 Feb 2024 15:01:39 +0800
Received: from kwepemd100004.china.huawei.com ([7.221.188.31]) by kwepemd100004.china.huawei.com ([7.221.188.31]) with mapi id 15.02.1258.028; Tue, 27 Feb 2024 15:01:39 +0800
From: Tianran Zhou <zhoutianran@huawei.com>
To: Roman Danyliw <rdd@cert.org>, The IESG <iesg@ietf.org>
CC: "draft-ietf-ippm-ioam-yang@ietf.org" <draft-ietf-ippm-ioam-yang@ietf.org>, "ippm-chairs@ietf.org" <ippm-chairs@ietf.org>, "ippm@ietf.org" <ippm@ietf.org>, "marcus.ihlar@ericsson.com" <marcus.ihlar@ericsson.com>, "Zhukeyi(Kaiyin,Datacom Standard&Patent)" <zhukeyi@huawei.com>
Thread-Topic: Roman Danyliw's No Objection on draft-ietf-ippm-ioam-yang-11: (with COMMENT)
Thread-Index: AQHaaPNLp1f5TE1QNkmP/uvA9rVn5LEdeAhQ
Date: Tue, 27 Feb 2024 07:01:39 +0000
Message-ID: <2e81d0b870f14614a35e5691a56194e0@huawei.com>
References: <170897969406.27306.3570243818335414506@ietfa.amsl.com>
In-Reply-To: <170897969406.27306.3570243818335414506@ietfa.amsl.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.112.40.118]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/Qn8VETwn44asRFkvStzVAd7QafA>
Subject: Re: [ippm] Roman Danyliw's No Objection on draft-ietf-ippm-ioam-yang-11: (with COMMENT)
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ippm/>
List-Post: <mailto:ippm@ietf.org>
List-Help: <mailto:ippm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Feb 2024 07:02:09 -0000
Hi Roman, Thanks for your comments. Please see inline. Best, Tianran -----Original Message----- From: Roman Danyliw via Datatracker [mailto:noreply@ietf.org] Sent: Tuesday, February 27, 2024 4:35 AM To: The IESG <iesg@ietf.org> Cc: draft-ietf-ippm-ioam-yang@ietf.org; ippm-chairs@ietf.org; ippm@ietf.org; marcus.ihlar@ericsson.com; marcus.ihlar@ericsson.com Subject: Roman Danyliw's No Objection on draft-ietf-ippm-ioam-yang-11: (with COMMENT) Roman Danyliw has entered the following ballot position for draft-ietf-ippm-ioam-yang-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-yang/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 3.5. Editorial The "pot-profile" contains the detailed information for the proof of transit data. Wouldn’t it be more accurate to say “The ‘pot-profile is intended to contain the detailed information …”. As defined now, it contains no details. ZTR> Agreed. Thanks. ** Section 5 /ioam/ioam-profiles/ioam-profile The entries in the list above include the whole IOAM profile configurations which indirectly create or modify the device configurations. Unexpected changes to these entries could lead to the mistake of the IOAM behavior for the corresponding flows. Since this section is discussing Security Considerations, what are the security consequences of “mistake[n] … IOAM behavior”? Is any of the scope of the Security Considerations of RFC9197 relevant? ZTR> I just read about RFC9197. I think the security considerations cover the management attack. Specifically, "At the management plane, attacks can be set up by misconfiguring or by maliciously configuring IOAM-enabled nodes in a way that enables other attacks. IOAM configuration should only be managed by authorized processes or users." I can also add some content about the consequences of the mistake behavior. **Section 5. This text has no discussion of sensitivities to reading this YANG modules? Is there any risk in a completely readable version of this YANG module? ZTR> Yes. The readable information might give information about the underlying network as well as services deployed for the customers. For instance, a customer might be given access to monitor their services status. In that example, the customer access should be restricted to nodes representing their services so as not to divulge information about the underlying network structure or others customers services.
- [ippm] Roman Danyliw's No Objection on draft-ietf… Roman Danyliw via Datatracker
- Re: [ippm] Roman Danyliw's No Objection on draft-… Tianran Zhou