I have a couple of comments and questions on philatelist. Overall, I think this is important work, and I’m happy to see someone is working on it!
1) In access-g it seems there is a reason why an identityref for method, and containers with when statements were used instead of a choice with similarly named containers. The obvious awkwardness of configuring something like: method get-local-url-once get-static-url-once url https://bogo vs: get-static-url-once url https://bogo I am curious to understand what reasons went into this decision. I suspect it was for extensibility to make it easier for someone to expand on the available options. 2) For the access-path I noticed that there was not a way to deal with paths that may themselves require a literal dollar sign followed by a literal parenthesis. While this may not seem like a very likely path, it may be technically possible in some systems. I was thinking a more complicated, but also more flexible solution would be to use the IETF proposed standard URI Template https://datatracker.ietf.org/doc/html/rfc6570 I think this might allow the easier construction of some more complicated URIs, and is also simple enough for the usual case, which would be something like: /if:interfaces/interface[name='{interfaces_interface_name}']/statistics/in-unicast-pkts However, this solution has the same problem that there seems to be no way to escape the braces! However, since literal braces are considered unsafe for URIs in general, I think that is the reason, since you can just use percent encoding on the braces for a URI. I think the challenge is that while access-path may often _be_ a URI, it is not guaranteed to be so. In addition, adding URI Template as a requirement for any implementation does add some challenge although several libraries do exist. So, I don't think URI Template works unless we can say that the access-path is a URI fragment. Another option might be to simply document that two dollar signs will be converted into a single dollar sign, or pick an existing standard template language. 3) For device-groups it may be useful to allow the user to reference some other part of the data model for the definition of some device-group. For example, a path, using the same syntax as the abbreviated xpath syntax used for leafref type in YANG could be used to reference some other set of leafs or a leaf-list. If this could use operational as well as config data, then it would be straightforward to reference for example an NSO device-group member list: /devices/device-group[name='NE']/member. Thanks, James
_______________________________________________ netmod mailing list -- netmod@ietf.org To unsubscribe send an email to netmod-le...@ietf.org
