On Wed, May 25, 2022 at 1:36 AM Jürgen Schönwälder < [email protected]> wrote:
> 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. > > You could use a subtree filter with a get* operation from NETCONF if the server supports the 'operation' resources. You can add a feature request to the restconf-next issue list https://github.com/netconf-wg/restconf-next/issues /js > Andy > > 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/> > > _______________________________________________ > netconf mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netconf >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
