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:[email protected]] 发送时间: 2022年5月25日 15:22 收件人: 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 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
