[NMOP] SIMAP Issue 113: Sergio Belotti - Service->Resource
Olga Havel <olga.havel@huawei.com> Tue, 03 February 2026 13:40 UTC
Return-Path: <olga.havel@huawei.com>
X-Original-To: nmop@mail2.ietf.org
Delivered-To: nmop@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id D6043B12A9EA for <nmop@mail2.ietf.org>; Tue, 3 Feb 2026 05:40:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -4.195
X-Spam-Level:
X-Spam-Status: No, score=-4.195 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JJG0byG0dV6x for <nmop@mail2.ietf.org>; Tue, 3 Feb 2026 05:40:02 -0800 (PST)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256)) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 8D36AB12A9E3 for <nmop@ietf.org>; Tue, 3 Feb 2026 05:40:02 -0800 (PST)
Received: from mail.maildlp.com (unknown [172.18.224.83]) by frasgout.his.huawei.com (SkyGuard) with ESMTPS id 4f54Mh3lh0zJ46CP; Tue, 3 Feb 2026 21:39:12 +0800 (CST)
Received: from frapema100007.china.huawei.com (unknown [7.182.19.38]) by mail.maildlp.com (Postfix) with ESMTPS id 00D5640569; Tue, 3 Feb 2026 21:40:00 +0800 (CST)
Received: from frapema500007.china.huawei.com (7.182.19.81) by frapema100007.china.huawei.com (7.182.19.38) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.36; Tue, 3 Feb 2026 14:39:59 +0100
Received: from frapema500007.china.huawei.com ([7.182.19.81]) by frapema500007.china.huawei.com ([7.182.19.81]) with mapi id 15.02.1544.011; Tue, 3 Feb 2026 14:39:59 +0100
From: Olga Havel <olga.havel@huawei.com>
To: "Belotti, Sergio (Nokia - IT)" <sergio.belotti@nokia.com>, "nmop@ietf.org" <nmop@ietf.org>
Thread-Topic: SIMAP Issue 113: Sergio Belotti - Service->Resource
Thread-Index: AdyVEK16RMHyoLdoTveToRPoVuR2Mg==
Date: Tue, 03 Feb 2026 13:39:59 +0000
Message-ID: <aea840c7531148639912d51fdc0c903b@huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.206.138.9]
Content-Type: multipart/alternative; boundary="_000_aea840c7531148639912d51fdc0c903bhuaweicom_"
MIME-Version: 1.0
Message-ID-Hash: OTZAS4MCSUVM5MVY5BHYZ5AQNL55DBVC
X-Message-ID-Hash: OTZAS4MCSUVM5MVY5BHYZ5AQNL55DBVC
X-MailFrom: olga.havel@huawei.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [NMOP] SIMAP Issue 113: Sergio Belotti - Service->Resource
List-Id: "Network Management Operations (NMOP) Working Group" <nmop.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/nmop/SD0t1M9PdodJaXVQztuVCXhBXMA>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nmop>
List-Help: <mailto:nmop-request@ietf.org?subject=help>
List-Owner: <mailto:nmop-owner@ietf.org>
List-Post: <mailto:nmop@ietf.org>
List-Subscribe: <mailto:nmop-join@ietf.org>
List-Unsubscribe: <mailto:nmop-leave@ietf.org>
Hi Sergio, Your comment in regards to Section 3.1.1 is as follows: The text is a bit confused. . In this text seems as though the SIMAP is a set of APIs related to various services, while in other previous part of the text I was supposing SIMAP is a data model for topology. The basic concept I can understand here is that SIMAP should be able to have enough information to permit an application to retrieve , as written " the topology for selected services". The rest of the text would need to be simplified and maybe is not needed. We clarified already relation between API and Model and as Benoit suggested, the client application access the model via APIs so the use cases can still use API term. We added the SIMAP API, SIMAP client application and SIMAP server definitions for clarification. We also addressed the issue 125 https://github.com/ietf-wg-nmop/draft-ietf-nmop-digital-map-concept/issues/125 based on Chongfeng comment to clarify the motivation and added some text that Christopher Janz suggested. The current section is as follows, please let me know if anything is still confusiong. I propose to close the Issue 113. Service -> Resource The SIMAP APIs can be invoked to retrieve all Services for selected service types. A SIMAP client application that triggers such a request will be able to retrieve the topology for selected Services via the SIMAP APIs and, from the response, it will be able to navigate top-down to the lower layers via the supporting relationship provided by the SIMAP server. In doing so, the SIMAP client application will be able to determine what logical resources are used by a Service. The supporting relations to the lowest layer, provided by the SIMAP server, will help the SIMAP client application to determine what physical resources are used by the Service. This addresses a requirement for systems to be able to provide topology and resource views of services, at different levels of abstraction, using the SIMAP [REF: ETSI ZSM 019 Clause 6]. Knowing the physical resources a service uses enables capacity planning, fault isolation, performance monitoring, and accurate billing. Best Regards, Olga
- [NMOP] SIMAP Issue 113: Sergio Belotti - Service-… Olga Havel
- [NMOP] Re: SIMAP Issue 113: Sergio Belotti - Serv… Sergio Belotti (Nokia)
- [NMOP] Re: SIMAP Issue 113: Sergio Belotti - Serv… Olga Havel