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.
/js 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:[email protected]] > 发送时间: 2022年5月25日 16:18 > 收件人: 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 > > 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:[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/lis > > > t-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/> > > -- > 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
