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/> _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
