Re: [netmod] [netconf] 答复: 答复: 答复: A question about YANG identifier design
Andy Bierman <andy@yumaworks.com> Wed, 25 May 2022 18:19 UTC
Return-Path: <andy@yumaworks.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 33A38C2740C5 for <netmod@ietfa.amsl.com>; Wed, 25 May 2022 11:19:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks.com
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 YvPANlMihH0u for <netmod@ietfa.amsl.com>; Wed, 25 May 2022 11:19:14 -0700 (PDT)
Received: from mail-yb1-xb30.google.com (mail-yb1-xb30.google.com [IPv6:2607:f8b0:4864:20::b30]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 CC88BC2CE8E4 for <netmod@ietf.org>; Wed, 25 May 2022 11:19:14 -0700 (PDT)
Received: by mail-yb1-xb30.google.com with SMTP id x2so37332529ybi.8 for <netmod@ietf.org>; Wed, 25 May 2022 11:19:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=/ZaGX7kxCs5JPZa7Br0NLbBMLzLdktRtCqrdcqiRVpM=; b=TDj4aGhUSqI+Z1Iwi2dO4CIhZgIuzZ4CBI2jePGhu8TaIZMqULy7ka9Ex/2oNgmQE2 6+oDTQrLrwxh2y89CVaE7BGgFQkT2haY0vkQWvYRIPh7KgJkhiFRGAByjQoCONkdwqQv taDXVrKNxv0xc0xHD87dnEh54bz48fbykj3joj0x75M/C88VW5r80ub6spVgcxQDq+P3 yy4CmnKB/wtJMjW89xW2Zyu1FqMgA1KC0ZemCgXdWbaAT99bKq2fJHiTLZjkc0ZVGK/T Y2fXZrqs2PqxwHr05L4orWcWKBne3lGK97AnVrwLtpIH6qspCoPwyQgcP5RJR9PQq1zp 7xKA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=/ZaGX7kxCs5JPZa7Br0NLbBMLzLdktRtCqrdcqiRVpM=; b=8H4Xyf1aU3uLahjKyLwAUkb/tfWMw9OsCTAk90gFz0jzNrJYmuSaYES0TPQUqOK5+f XIZVSPvaaVtRQRJ1Qfqf2RNGY55jdlwHesjh4oMocjnIZ3ZXpz430z0nh2HFdCc8jb1y I7/WIa3PeYphuqCn1paoKqYTihZeOeP7om85+elrdxVcYk9rLsMB+b0tI6P3CCEkIrYN SVBZDjMLYNQRVzuH+jvi9znP+ZLqWzde9VB7YLNgPKyEasopdppesEjV7frt4oxSvmxK 9cqzXlipUYqVmvBhAaEUXyepAzHeCI51gmbPBwCc2zwxiNigZm9jkhDG3b7VFMpqxoWc tbrw==
X-Gm-Message-State: AOAM5325snaDJj9vXBIE6eGWuBfQilPeFULtu9XjC1Bp0do6giLuU2NE FFNnUpTGBlI6rwuHYHDTd8Y7m/OZzF7oKkqm4cTj3Q==
X-Google-Smtp-Source: ABdhPJwGBq8waeKww4Y1oHvNnuvWQlW4/QbFeZ866uzU4AXauWRe9oTPuGtMLenwcyw1soGLHvPiiPRUIrxe5Ed08s8=
X-Received: by 2002:a25:8183:0:b0:64f:690c:7c68 with SMTP id p3-20020a258183000000b0064f690c7c68mr24580197ybk.197.1653502753252; Wed, 25 May 2022 11:19:13 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <20220525083544.ymzco56byey5zt4w@anna>
From: Andy Bierman <andy@yumaworks.com>
Date: Wed, 25 May 2022 11:19:02 -0700
Message-ID: <CABCOCHR_DMSqksjuWPNkA8ETjPocL7RaFm=0VK8mkJ4cTq07vQ@mail.gmail.com>
To: Jürgen Schönwälder <j.schoenwaelder@jacobs-university.de>, 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>
Content-Type: multipart/alternative; boundary="0000000000003e4e2e05dfda1c3d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/58BkhVqxbStT1HbOH8OoiRhY4Lw>
Subject: Re: [netmod] [netconf] 答复: 答复: 答复: 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 18:19:19 -0000
On Wed, May 25, 2022 at 1:36 AM Jürgen Schönwälder < j.schoenwaelder@jacobs-university.de> wrote: > 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. > > You could use a subtree filter with a get* operation from NETCONF if the server supports the 'operation' resources. You can add a feature request to the restconf-next issue list https://github.com/netconf-wg/restconf-next/issues /js > Andy > > 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/lis > > > > 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/> > > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf >
- [netmod] A question about YANG identifier design yuchaode
- Re: [netmod] A question about YANG identifier des… Jürgen Schönwälder
- [netmod] 答复: A question about YANG identifier des… yuchaode
- Re: [netmod] 答复: A question about YANG identifier… Jürgen Schönwälder
- [netmod] 答复: 答复: A question about YANG identifier… yuchaode
- Re: [netmod] 答复: 答复: A question about YANG identi… Jürgen Schönwälder
- [netmod] 答复: 答复: 答复: A question about YANG identi… yuchaode
- Re: [netmod] 答复: 答复: 答复: A question about YANG id… Jürgen Schönwälder
- [netmod] 答复: 答复: 答复: 答复: A question about YANG id… yuchaode
- Re: [netmod] A question about YANG identifier des… Jan Lindblad
- Re: [netmod] 答复: 答复: A question about YANG identi… Kent Watsen
- Re: [netmod] A question about YANG identifier des… Kent Watsen
- Re: [netmod] [netconf] 答复: 答复: 答复: A question abo… Andy Bierman
- [netmod] 答复: A question about YANG identifier des… yuchaode
- [netmod] 答复: A question about YANG identifier des… yuchaode
- [netmod] 答复: [netconf] 答复: 答复: 答复: A question abo… yuchaode
- Re: [netmod] 答复: A question about YANG identifier… Robert Varga
- [netmod] 答复: 答复: A question about YANG identifier… yuchaode
- Re: [netmod] A question about YANG identifier des… Jan Lindblad
- [netmod] Unintended conequences wasRe: [netconf] … tom petch