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/list-b/list-c={leaf-5}
>
>
> -----邮件原件-----
> 发件人: Jürgen Schönwälder [mailto:[email protected]]
> 发送时间: 2022年5月24日 18:16
> 收件人: yuchaode <[email protected]>
> 抄送: '[email protected]' <[email protected]>; '[email protected]'
> <[email protected]>; Fatai Zhang <[email protected]>; Zhenghaomian
> <[email protected]>; liuzhoulong <[email protected]>; Chenchunhui
> (C) <[email protected]>
> 主题: 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
> > [email protected]
> > 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/>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
