Re: [netmod] A question about YANG identifier design

Jan Lindblad <> Tue, 31 May 2022 08:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A85B2C14F74D; Tue, 31 May 2022 01:45:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.904
X-Spam-Status: No, score=-1.904 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xws2V1BJXZw6; Tue, 31 May 2022 01:45:33 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 83950C14F74E; Tue, 31 May 2022 01:45:33 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTPSA id DB2531AE08F1; Tue, 31 May 2022 10:45:30 +0200 (CEST)
From: Jan Lindblad <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_87379D40-B80E-4364-AF0C-91064421DCA3"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.\))
Date: Tue, 31 May 2022 10:45:30 +0200
In-Reply-To: <>
Cc: Jürgen Schönwälder <>, "" <>, "" <>, Fatai Zhang <>, Zhenghaomian <>, liuzhoulong <>, "Chenchunhui (C)" <>
To: yuchaode <>
References: <> <20220524101546.cfzkzi55dsutfyic@anna> <> <20220525072213.udkoy7lejf2qk2iq@anna> <> <20220525081828.kwpbiw43ck4wizw2@anna> <> <20220525083544.ymzco56byey5zt4w@anna> <> <> <>
X-Mailer: Apple Mail (2.3696.
Archived-At: <>
Subject: Re: [netmod] A question about YANG identifier design
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: NETMOD WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 31 May 2022 08:45:37 -0000


> Thank you, Jan!
> Yes, for whose people who are familiar with REST paradigm, a lot of RESTCONF designs look twisted and not as flexible and straightforward as REST interface. If, as you say, these are some compromises introduced to address some other issues, it is understandable.

Right. From the perspective of a network management purist like myself, there are a lot of plain REST designs that look twisted and not as useful for automation as a straightforward RESTCONF interface :-)

> Returning to our previous discussion, if RESTCONF suggests to use a readable string format, like name, as identifier, it is better to provide a format constraint when designing YANG modules. I found a lot of YANG modules is lack of this job.

Well, I don't see much point at restricting names given to objects by users. They should be free to name them however they like, so that the naming principles they use have meaning in the context where they operate.

> Since name is used as an identifier, it must be globally unique.

No, that is a misconception. In the YANG and RESTCONF world, the names are scoped to the parent object. You add the schema path to construct the globally unique resource identifier.

> This is a difficult job, considering in different scenarios, this name could be specified by RESTCONF client and server at the same time. If the data stored in different systems is inconsistent, it is difficult to ensure that this name identifier is global unique. So usually a lot of system would prefer to use UUID for identifier.

I'm not sure I follow your use case here, but I agree that keeping things fully consistent between client and server is key. Constructing globally unique ids requires some thought. UUIDs are not the only possible answer, or even the best one if humans need to deal with them.

> I think, for this name identifier, systems could use UUID when doing implementation. Because UUID is also a string format. The problem is it is a little bit weird when doing integration. For example, if the name is using UUID format, the readable label must to be set to another attribute, such as alias .etc. It is not perceptible for programing interface between application, but a lot of explanation is needed when the developers begin to interact this interface.

Clients that wish to use UUIDs for naming objects should be free to do so. In some cases that may not be possible, as for example many systems will have restrictions on what names you give to interfaces, etc.

But I think we're missing the point here. YANG is supposed to reduce the gap between what a traditional human operator sees and works with, and make sure the automation interface is using the same object names etc. We have tried separating human interfaces from programmatic interfaces in many management interfaces in the past (SNMP, etc), and the fact that objects were called different things in the different interfaces invariably caused a lot of unnecessary trouble for automation projects.

> I think when design YANG module, it is better to define an id attribute which should use UUID format and define name attribute to specify readable label. The UUID information could be hided, just like you said, when using in GUI.

I disagree. Experience shows this is a problematic approach, and counter to YANG's goals. In some cases it is a good idea to do what you say, and YANG module authors can model things like that if they wish. But to make that a general rule everywhere is not a good idea in my opinon. Not at all.

Robert Varga wrote:

>> The key point there is that URIs imply an extensible structure, which neither strings nor UUIDs convey.
>> The tie in is into URI namespace -- and how exactly an implementation or deployment does that is up for grabs.
>> For example you can use URNs, and specifically "urn:uuid:XXXX", et voila, you are using UUIDs, but everybody who sees that identifier knows it is a UUID, not just something that happens to look like an UUID in the sample that you've observed during integration.
>> Or you can design your own URNs, and say that we have three separate namespaces in urn:com:example:id:{network,node,link} and each of them is used to assign identifiers for networks, nodes, links -- and enforce that at system boundaries.
>> Suddenly your identifiers are type-safe and errors like are either completely preventable by system input validation or obvious to humans communicating them:
>> A: Can you deactivate application "urn:com:example:id:site:XYZ", please?
>> B: Right, but that's not an application ID!
> An excellent example! 
> This make me realize that my previous understanding is a little bit shallow. Especially it make me clear how can this URI identifier be human readable and programing safe.
> What a pity is that not all the YANG models define in IETF are using this URI identifier. This leaves them fragmented, independent, unable to play to the strengths of one system. Sometime some ID conversion interfaces would be needed if we want to use these models at the same time. This is ludicrous in the integration progress.
> Anyhow, many thanks to Robert!

Actually, Robert's example of self-typed references is not far from what we have in YANG. Compare these two globally unique object identifiers:
+ "urn:com:example:id:site:XYZ"
+ "/example:sites/site[id='XYZ']"

The latter, of course, gives a hierarchical view of the world that is compatible with how humans think and operate today, and allow operators to use short and comprehensible names like XYZ.

Best Regards,