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

Robert Varga <nite@hq.sk> Fri, 27 May 2022 13:09 UTC

Return-Path: <nite@hq.sk>
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 576F8C15EB2D for <netmod@ietfa.amsl.com>; Fri, 27 May 2022 06:09:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.956
X-Spam-Level:
X-Spam-Status: No, score=-8.956 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-1.857, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hq.sk
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 Usj8WuYbPrla for <netmod@ietfa.amsl.com>; Fri, 27 May 2022 06:09:31 -0700 (PDT)
Received: from mail.hq.sk (hq.sk [81.89.59.181]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 581C0C15AE20 for <netmod@ietf.org>; Fri, 27 May 2022 06:09:30 -0700 (PDT)
Received: from [172.16.4.37] (46.229.239.158.host.vnet.sk [46.229.239.158]) by mail.hq.sk (Postfix) with ESMTPSA id A78B2246665; Fri, 27 May 2022 15:09:26 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hq.sk; s=mail; t=1653656966; bh=VaP8CB5yJGnAzwVeRd3GmKV1ELf3GH71ixvTN8Gmzvw=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=XAaki+dO3Ln5dlhf6nIcDXJs4ZRrDo8dcdh0YvdugsXFQ/ME7UH0YblcdXkiYeHwr BuPXAR4vUKjQak6ddnjYCw1jdEnwXrGC/UesHL/p20kWD46Wo/17gKqLSe1U5Ks28U uqIqYi6CWX9R/Czq/PzTTxvpwb7J83Ve/XEyJ9G8=
Message-ID: <f21421e9-075b-cddd-5e86-fecc95fc9647@hq.sk>
Date: Fri, 27 May 2022 15:09:25 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1
Content-Language: en-US
To: yuchaode <yuchaode=40huawei.com@dmarc.ietf.org>, '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>
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>
From: Robert Varga <nite@hq.sk>
In-Reply-To: <e4a2925caf354fe98100576ddd621c79@huawei.com>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="------------VNRnCguCmPPUeiYXkRYT0wr0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/l7sb6b3Xdz9TMpummWjopUjJR0Q>
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: Fri, 27 May 2022 13:09:37 -0000

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