[netmod] A question about YANG identifier design

yuchaode <yuchaode@huawei.com> Tue, 24 May 2022 09:39 UTC

Return-Path: <yuchaode@huawei.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F54AC14F725; Tue, 24 May 2022 02:39:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.8
X-Spam-Level:
X-Spam-Status: No, score=-1.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 FE-9s1HBe1wm; Tue, 24 May 2022 02:39:33 -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 1B525C14F722; Tue, 24 May 2022 02:39:33 -0700 (PDT)
Received: from fraeml737-chm.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4L6pvz4Hy8z684th; Tue, 24 May 2022 17:35:27 +0800 (CST)
Received: from canpemm100004.china.huawei.com (7.192.105.92) by fraeml737-chm.china.huawei.com (10.206.15.218) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Tue, 24 May 2022 11:39:29 +0200
Received: from canpemm500002.china.huawei.com (7.192.104.244) by canpemm100004.china.huawei.com (7.192.105.92) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Tue, 24 May 2022 17:39:21 +0800
Received: from canpemm500002.china.huawei.com ([7.192.104.244]) by canpemm500002.china.huawei.com ([7.192.104.244]) with mapi id 15.01.2375.024; Tue, 24 May 2022 17:39:21 +0800
From: yuchaode <yuchaode@huawei.com>
To: "'netmod@ietf.org'" <netmod@ietf.org>, "'netconf@ietf.org'" <netconf@ietf.org>
CC: Fatai Zhang <zhangfatai@huawei.com>, Zhenghaomian <zhenghaomian@huawei.com>, liuzhoulong <liuzhoulong@huawei.com>, "Chenchunhui (C)" <chenchunhui@huawei.com>
Thread-Topic: A question about YANG identifier design
Thread-Index: AdhvOu0xIH19YvLwR0Osau4pGWfJYw==
Date: Tue, 24 May 2022 09:39:21 +0000
Message-ID: <de9b838f10a448c9991d0a381d426716@huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.117.175.195]
Content-Type: multipart/alternative; boundary="_000_de9b838f10a448c9991d0a381d426716huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/1V9jvbSGvDDgjw5LJcV-lv6YjVw>
Subject: [netmod] A question about YANG identifier design
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 May 2022 09:39:35 -0000

Hello friends,

I have got some puzzles about YANG model design, to be more specific, it is about the identifier design in YANG model.

As we know, YANG model is a tree-like structure, different objects are defined in different branches according their different levels. E.G. there is such a YANG tree:
module: ietf-example
   +--rw root
      +--rw list-a* [leaf-1]
         +--rw leaf-1    yang:uuid
         +--rw leaf-2?   string
         +--rw list-b* [leaf-3]
            +--rw leaf-3    yang:uuid
            +--rw leaf-4?   string
            +--rw list-c* [leaf-5]
               +--rw leaf-5    yang:uuid
               +--rw leaf-6?   string
List-c is child object of list-b and list-b is child object of list-a.

If we want to retrieve a list-c instance, we need to know his parent list-b's and his grandparent list-a's identifier to construct a RESTCONF GET request URL:
https://{{host:port}}/{{restconf}}/data/ietf-example:root/list-a={leaf-1}/list-b={leaf-3}/list-c={leaf-5}.
However, you can easily find that the identifier of list-a, list-b and list-c are all UUID format. Usually, UUID is required to be unique globally. If the RESTCONF server complies with UUID requirement strictly, the identifier of list-b and list-a are redundant.

Similarly, if there is a YANG data model want to reference list-c in its model, the reference identifier should include list-b and list-a's identifier at the same time besides list-c's identifier. If this list-c instance repeat a lot of time in this data model, there would be a lot of redundant list-b & list-a's identifier.

Besides, this hierarchical identifier brings some problems when we are designing generic model. For example, if we want to design an alarm model, considering that the main information of alarm includes alarm ID, alarm level, tips message, location etc. which are generic for all inventory objects, it is easy for us to choose to design a generic model. For the inventory object alarm happened on, we would like to use a generic inventory resource type and resource UUID to specify. But if we use hierarchical identifier, considering alarm could be happened on NE, board or port .etc. and NE contains boards and board contains ports, we cannot use a generic identifier attribute to specify NE, board and port at the same time. For NE, we need to use one attribute to define its ne-id. And for board we need two attributes to define its id, ne-id and board-id. And for port, we need three attributes to define its id, ne-id, board-id and port-id.

So I am wondering if for those objects which are using UUID as identifier, the server should implement this UUID globally unique. When retrieving these objects, there is no necessary to specify their parent's and grandparent's identifier. Just take the list-c retrieval above for example, the URL could be changed to be:
https://{{host:port}}/{{restconf}}/data/ietf-example:root/list-a/list-b/list-c={leaf-5}<https://%7b%7bhost:port%7d%7d/%7b%7brestconf%7d%7d/data/ietf-example:root/list-a/list-b/list-c=%7bleaf-5%7d>. And for model object reference scenario, we can also use list-c's identifier only.

This is just my consideration, any comments are welcome! Thank you!

B.R.
Chaode