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
>