James, Many thanks for taking the time to review, and for great suggestions! Comments inline marked [janl].
From: James Henderson <[email protected]> Date: Thursday, 6 June 2024 at 19:53 To: [email protected] <[email protected]> Subject: [netmod] Comments on draft-lindblad-tlm-philatelist-01 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. [janl] Exactly. By using a discriminator design (the method leaf) with an identity type, plus containers with detailed settings, it will be easy to expand this model. It would be easy both to add new variants of the already existing methods as well as completely new methods. Let me show an example of each. Example 1: Variant method Let’s say someone comes up with a variant of the get-local-url-once where the document fetched by the URL contains information about many different kinds of devices, each under a different section header. To allow this sort of file to be used, the user would have to additionally configure which section should be read in the file pointed to by the URL. To add this possibility in YANG, something like the following would be required: module get-local-url-section-once { namespace blabla prefix import … identity get-static-url-section-once { base ietf-tlm-philatelist-types:get-static-url-once; } augment /ietf-tlm-philatelist-collector:tlm-collector/ ietf-tlm-philatelist-collector:organizations/ ietf-tlm-philatelist-collector:organization/ ietf-tlm-philatelist-collector:device-groups/ ietf-tlm-philatelist-collector:device-group/ ietf-tlm-philatelist-collector:accesses/ ietf-tlm-philatelist-collector:access/ ietf-tlm-philatelist-collector:get-static-url-once { when "derived-from-or-self(../method, 'ietf-tlm-philatelist-types:get-static-url-section-once')"; leaf section-heading { type ietf-tlm-philatelist-types:something; } } } } Example 2: Completely new method Let’s say someone comes up with a completely collection method, e.g. “SNMP v8” 😊 It could be added like this: module tlm-snmpv8-subscribe { namespace blabla prefix import … identity snmpv8-subscribe { base ietf-tlm-philatelist-types:connection-method; } augment /ietf-tlm-philatelist-collector:tlm-collector/ ietf-tlm-philatelist-collector:organizations/ ietf-tlm-philatelist-collector:organization/ ietf-tlm-philatelist-collector:device-groups/ ietf-tlm-philatelist-collector:device-group/ ietf-tlm-philatelist-collector:accesses/ ietf-tlm-philatelist-collector:access { when "derived-from-or-self(method, 'ietf-tlm-philatelist-types:snmpv8-subscribe')"; // <all the snmpv8 subscription relevant details here> } } } Hope this explains why I did it this way. We may of course decide that we don’t need this level of flexibility, or that we can achieve a sufficient level of flexibility using some other design. This was just my initial proposal, discussion welcome. 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. [janl] Thanks! I had entirely missed RFC 6570. While perhaps not aimed exactly at our specific use case, I think it will be useful, and certainly better than the home cooked syntax I invented. If curly braces would be needed in the URL, I guess they could always be represented as %7b and %7d. I’ll introduce this in the next draft version, unless someone teaches me why this isn’t a great idea. 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. [janl] Since many people might be using a controller that already has a device-group concept, I certainly understand how referencing pre-existing device-groups could be (very) useful. It’s certainly an interesting and relevant idea, but if that’s the way to build an interoperable standard, I’m not yet sure. For pointing to an existing config true list anywhere in the YANG tree, I think the YANG instance-identifier type would be the best choice. I don’t think we’d want to allow pointing to config false lists, as that would go against one of the fundamental principles of YANG regarding config true references to config false data. Once again, thank you for the review, this is really good feedback. Best Regards, /Jan
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
