[netmod] 答复: 答复: A question about YANG identifier design

yuchaode <yuchaode@huawei.com> Sat, 28 May 2022 01:53 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 B1102C14F72C for <netmod@ietfa.amsl.com>; Fri, 27 May 2022 18:53:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 eG6G2u-H5D6v for <netmod@ietfa.amsl.com>; Fri, 27 May 2022 18:53:38 -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 1BC97C14F607 for <netmod@ietf.org>; Fri, 27 May 2022 18:53:38 -0700 (PDT)
Received: from fraeml710-chm.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4L94NK09NZz67jxm for <netmod@ietf.org>; Sat, 28 May 2022 09:49:21 +0800 (CST)
Received: from canpemm500010.china.huawei.com (7.192.105.118) by fraeml710-chm.china.huawei.com (10.206.15.59) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Sat, 28 May 2022 03:53:33 +0200
Received: from canpemm500002.china.huawei.com (7.192.104.244) by canpemm500010.china.huawei.com (7.192.105.118) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Sat, 28 May 2022 09:53:31 +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; Sat, 28 May 2022 09:53:31 +0800
From: yuchaode <yuchaode@huawei.com>
To: 'Robert Varga' <nite@hq.sk>, 'Kent Watsen' <kent+ietf@watsen.net>
CC: "netmod@ietf.org" <netmod@ietf.org>, "Chenchunhui (C)" <chenchunhui@huawei.com>, liuzhoulong <liuzhoulong@huawei.com>, Fatai Zhang <zhangfatai@huawei.com>, Zhenghaomian <zhenghaomian@huawei.com>
Thread-Topic: [netmod] 答复: A question about YANG identifier design
Thread-Index: AQHYccsqj2q4WD1aGk+mAotNCIFRua0zgKjw
Date: Sat, 28 May 2022 01:53:31 +0000
Message-ID: <0988dc4a71c044a68f3a13e32a7c7860@huawei.com>
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> <01000180fc2d869d-8284af4c-ba30-4e21-9824-d99d03f260f3-000000@email.amazonses.com> <e4a2925caf354fe98100576ddd621c79@huawei.com> <f21421e9-075b-cddd-5e86-fecc95fc9647@hq.sk>
In-Reply-To: <f21421e9-075b-cddd-5e86-fecc95fc9647@hq.sk>
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: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/c2CRGI0MeVNwH5yxuJYtztRqrN0>
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: Sat, 28 May 2022 01:53:42 -0000

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!

Best Regards,
Chaode

-----邮件原件-----
发件人: netmod [mailto:netmod-bounces@ietf.org] 代表 Robert Varga
发送时间: 2022年5月27日 21:09
收件人: yuchaode <yuchaode=40huawei.com@dmarc.ietf.org>; 'Kent Watsen' <kent+ietf@watsen.net>
抄送: netmod@ietf.org; Chenchunhui (C) <chenchunhui@huawei.com>; liuzhoulong <liuzhoulong@huawei.com>; Fatai Zhang <zhangfatai@huawei.com>; Zhenghaomian <zhenghaomian@huawei.com>
主题: Re: [netmod] 答复: A question about YANG identifier design

On 26/05/2022 05:12, yuchaode wrote:
> Thanks Kent,
> 
> I think the common understanding with me for the benefit of string 
> format is that string format is generic and easy for implementation. 
> But I am still confused how can this URI string can help to correlate 
> identifiers across systems. Could you help to provide some more detail 
> information?

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 https://www.atlassian.com/engineering/april-2022-outage-update 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!

Regards,
Robert