Re: [netmod] A question about YANG identifier design

Jan Lindblad <janl@tail-f.com> Wed, 25 May 2022 09:12 UTC

Return-Path: <janl@tail-f.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 4DD14C14F612; Wed, 25 May 2022 02:12:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.799
X-Spam-Level:
X-Spam-Status: No, score=-6.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-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 7yGw8csEvNfI; Wed, 25 May 2022 02:12:15 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 02018C14F608; Wed, 25 May 2022 02:12:14 -0700 (PDT)
Received: from smtpclient.apple (unknown [173.38.220.54]) by mail.tail-f.com (Postfix) with ESMTPSA id E73601AE0352; Wed, 25 May 2022 11:12:12 +0200 (CEST)
From: Jan Lindblad <janl@tail-f.com>
Message-Id: <C9B52EA3-7A59-4936-B7C8-8999031A730C@tail-f.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_2F11A9B3-788A-455D-9A98-3FFF6B42D0CB"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.80.82.1.1\))
Date: Wed, 25 May 2022 11:12:11 +0200
In-Reply-To: <86c348fb32b14dda97644c8893057588@huawei.com>
Cc: Jürgen Schönwälder <j.schoenwaelder@jacobs-university.de>, "netmod@ietf.org" <netmod@ietf.org>, "netconf@ietf.org" <netconf@ietf.org>, Fatai Zhang <zhangfatai@huawei.com>, Zhenghaomian <zhenghaomian@huawei.com>, liuzhoulong <liuzhoulong@huawei.com>, "Chenchunhui (C)" <chenchunhui@huawei.com>
To: yuchaode <yuchaode=40huawei.com@dmarc.ietf.org>
References: <de9b838f10a448c9991d0a381d426716@huawei.com> <20220524101546.cfzkzi55dsutfyic@anna> <f97fd7815d8147a680798dd5159f0594@huawei.com> <20220525072213.udkoy7lejf2qk2iq@anna> <c85dc299766941f7b3749c1572c6ccb3@huawei.com> <20220525081828.kwpbiw43ck4wizw2@anna> <9af6251a5fbe4c338bace6cccece1cde@huawei.com> <20220525083544.ymzco56byey5zt4w@anna> <86c348fb32b14dda97644c8893057588@huawei.com>
X-Mailer: Apple Mail (2.3696.80.82.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/W3CE4r3CaY557xYl6EB1WaqsbKI>
Subject: Re: [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: Wed, 25 May 2022 09:12:20 -0000

Chaode,

> Thank you all the same for your comments!
> And I also find peaple who are designing YANG module in IETF don’t like to use uuid. They prefer to use a string for identifier. String type is generic and easy for implementation but there is not a good way to make it global unique and easy for reference.

UUIDs have many good properties for identifying objects in computer programs, but they are quite bad when presented to humans. After many years of experience with SNMP, TL/1, Corba and many other mechanisms for network management, the IETF initiative behind YANG was based on the idea to unite the human interfaces and the programming interfaces into a single model. This implies computer programs should use the same names, concepts and management structures as the humans do. This makes it easy to automate the tasks currently performed by humans.

Clearly, this is different from the Web/REST approach where a fundamental assumption is that someone is writing a user interface (web) application that works with UUIDs internally, but hides them from the user and presents some sort of human readable label for every human visible object. Nothing wrong with that, but it does not address the problem YANG was created to solve. YANG is also addressing many other issues seen historically, such as lack of transactionality. YANG's (nearly) complete interface declaration is fundamental to the model driven approach, and enables management application programming that is more than an order of magnitude faster/easier than earlier (the data I'm basing this statement on is not publicly available, I'm afraid).

To get the most value out of both worlds, you can use RESTCONF. For someone coming right out of the REST paradigm, RESTCONF will appear to have taken a few odd choices here and there, but overall I'd say it's a pretty good compromise.

Best Regards,
/jan



> -----邮件原件-----
> 发件人: Jürgen Schönwälder [mailto:j.schoenwaelder@jacobs-university.de <mailto:j.schoenwaelder@jacobs-university.de>] 
> 发送时间: 2022年5月25日 16:36
> 收件人: yuchaode <yuchaode@huawei.com <mailto:yuchaode@huawei.com>>
> 抄送: 'netmod@ietf.org <mailto:netmod@ietf.org>' <netmod@ietf.org <mailto:netmod@ietf.org>>; 'netconf@ietf.org <mailto:netconf@ietf.org>' <netconf@ietf.org <mailto:netconf@ietf.org>>; Fatai Zhang <zhangfatai@huawei.com <mailto:zhangfatai@huawei.com>>; Zhenghaomian <zhenghaomian@huawei.com <mailto:zhenghaomian@huawei.com>>; liuzhoulong <liuzhoulong@huawei.com <mailto:liuzhoulong@huawei.com>>; Chenchunhui (C) <chenchunhui@huawei.com <mailto:chenchunhui@huawei.com>>
> 主题: Re: 答复: 答复: 答复: [netmod] A question about YANG identifier design
> 
> I am not sure that listing specific types in a protocol specification is what I would do for a generic solution. Anyway, people who were actively involved in the design of RESTCONF should get involved in this discussion.
> 
> /js
> 
> On Wed, May 25, 2022 at 08:31:19AM +0000, yuchaode wrote:
>> How about the uuid type defined in RFC6991? I think it can be globally unique.
>> 
>> -----邮件原件-----
>> 发件人: Jürgen Schönwälder [mailto:j.schoenwaelder@jacobs-university.de]
>> 发送时间: 2022年5月25日 16:18
>> 收件人: yuchaode <yuchaode@huawei.com>
>> 抄送: 'netmod@ietf.org' <netmod@ietf.org>; 'netconf@ietf.org' 
>> <netconf@ietf.org>; Fatai Zhang <zhangfatai@huawei.com>; Zhenghaomian 
>> <zhenghaomian@huawei.com>; liuzhoulong <liuzhoulong@huawei.com>; 
>> Chenchunhui (C) <chenchunhui@huawei.com>
>> 主题: Re: 答复: 答复: [netmod] A question about YANG identifier design
>> 
>> I do not think there is currently a way to specify in YANG that a key of a list is globally unique and hence a generic protocol engine won't know which list key's have this property. I assume the current text is there to cover the case where keys are not unique and you like to drill down the data tree by processing the URL left to right.
>> 
>> /js
>> 
>> On Wed, May 25, 2022 at 08:06:13AM +0000, yuchaode wrote:
>>> Thank you for your reference.
>>> 
>>> That is where I think it's not reasonable. If the terminal branch list-c's identifier can be global unique, specifying its parent's and grandparent's identifier is redundant.
>>> Certainly, if list-c and its parent and grandparent identifier could not be global unique, that could be a problem. Multiple list-c instances would be return with a same identifier. 
>>> But how about list-b's and list-a's identifier are returned at the same time when querying list-c instance, if list-b and list-c's identifier could not be global unique and are not specified when querying?
>>> 
>>> -----邮件原件-----
>>> 发件人: Jürgen Schönwälder 
>>> [mailto:j.schoenwaelder@jacobs-university.de]
>>> 发送时间: 2022年5月25日 15:22
>>> 收件人: yuchaode <yuchaode@huawei.com>
>>> 抄送: 'netmod@ietf.org' <netmod@ietf.org>; 'netconf@ietf.org' 
>>> <netconf@ietf.org>; Fatai Zhang <zhangfatai@huawei.com>; 
>>> Zhenghaomian <zhenghaomian@huawei.com>; liuzhoulong 
>>> <liuzhoulong@huawei.com>; Chenchunhui (C) <chenchunhui@huawei.com>
>>> 主题: Re: 答复: [netmod] A question about YANG identifier design
>>> 
>>> RFC 8040 says on page 27 (good old times where RFCs still had page
>>> numbers):
>>> 
>>> If a data node in the path expression is a YANG list node, then the
>>> key values for the list (if any) MUST be encoded according to the
>>> following rules:
>>> 
>>> And also this one:
>>> 
>>> o All of the components in the "key" statement MUST be encoded.
>>> Partial instance identifiers are not supported.
>>> 
>>> /js
>>> 
>>> On Wed, May 25, 2022 at 01:36:43AM +0000, yuchaode wrote:
>>>> Thank you, Jürgen!
>>>> 
>>>> A generic identifier design is quite good for the other generic model design, just like the hardware components design mentioned by you.
>>>> But there have been some other models defined in a nesting level already, for example network topology and TE topology etc. If we want to reference a termination-point object, we need to specify its belonging network-id and node-id.
>>>> So for this kind of model, can we retrieve or reference terminal branch objects without its trunk branch objects' identifier if the RESTCONF server can guarantee the global uniqueness of terminal branch objects' identifier.
>>>> Just like the URL I mentioned in last email:
>>>> https://{{host:port}}/{{restconf}}/data/ietf-example:root/list-a/l
>>>> is
>>>> t-b/list-c={leaf-5}
>>>> 
>>>> 
>>>> -----邮件原件-----
>>>> 发件人: Jürgen Schönwälder
>>>> [mailto:j.schoenwaelder@jacobs-university.de]
>>>> 发送时间: 2022年5月24日 18:16
>>>> 收件人: yuchaode <yuchaode@huawei.com>
>>>> 抄送: 'netmod@ietf.org' <netmod@ietf.org>; 'netconf@ietf.org' 
>>>> <netconf@ietf.org>; Fatai Zhang <zhangfatai@huawei.com>; 
>>>> Zhenghaomian <zhenghaomian@huawei.com>; liuzhoulong 
>>>> <liuzhoulong@huawei.com>; Chenchunhui (C) <chenchunhui@huawei.com>
>>>> 主题: Re: [netmod] A question about YANG identifier design
>>>> 
>>>> You need to fit your data model to the data modeling language and the protocol. This can be a challenge at times but this is what it is.
>>>> 
>>>>> From what you are writing, it seems that you try to encode the
>>>> containment relationship of hardware components into the nesting 
>>>> levels of a YANG model. This is likely not a good idea to start 
>>>> with and this may be the root cause of the problems you are facing.
>>>> Note how RFC 8348 defines a hardware model that is essentially a 
>>>> flat list of hardware components and the containment relationship 
>>>> is modeled by additional contains-child etc. leafs. This approach 
>>>> gives us a simple /hardware/component/name that can be used to 
>>>> refer to any hardware component easily. Sure, the downside is that 
>>>> retrieving all components contained in another components is a bit 
>>>> more complex but being able to reference all hardware components 
>>>> in the same way likely is a big enough advantage to go for a flat 
>>>> list. (And once you think about it, the containment relationship 
>>>> is just one relationship, there may be others. By using a flat 
>>>> list with leafs, you can model multiple
>>>> relationships.)
>>>> 
>>>> /js
>>>> 
>>>> On Tue, May 24, 2022 at 09:39:21AM +0000, yuchaode wrote:
>>>>> 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
>>>>> 
>>>> 
>>>>> _______________________________________________
>>>>> netmod mailing list
>>>>> netmod@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>> 
>>>> 
>>>> -- 
>>>> Jürgen Schönwälder Jacobs University Bremen gGmbH
>>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
>>>> Fax: +49 421 200 3103 <https://www.jacobs-university.de/>
>>> 
>>> -- 
>>> Jürgen Schönwälder Jacobs University Bremen gGmbH
>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
>>> Fax: +49 421 200 3103 <https://www.jacobs-university.de/>
>> 
>> -- 
>> Jürgen Schönwälder Jacobs University Bremen gGmbH
>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
>> Fax: +49 421 200 3103 <https://www.jacobs-university.de/>
> 
> -- 
> Jürgen Schönwälder Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax: +49 421 200 3103 <https://www.jacobs-university.de/>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org <mailto:netmod@ietf.org>
> https://www.ietf.org/mailman/listinfo/netmod <https://www.ietf.org/mailman/listinfo/netmod>