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
