On Thu, May 19, 2022 at 12:05 AM Martin Björklund <[email protected]> wrote:
> Kent Watsen <[email protected]> wrote: > > > > > Hmm, I don't remember why this was changed in RFC 8525. Perhaps this > was by accident? The only text I can find is this in RFC 7950: > > Not by accident. I did not want the new list. The main rationale was that the 2 lists needed different keys. The import-only-module list has [name, revision] instead of just [name]. 5.6.5. Implementing a Module > > A server implements a module if it implements the module's data > nodes, RPCs, actions, notifications, and deviations. > > Which seems to indicate that "implementing a module" is NOT required > for a feature to be supported. > Agreed. - 7.20.1, para 1: not specific to modules, refers to the model - 7.20.1, para 6: "server MUST support all dependent features". No mention of modules, just features. > > 2) If it is the case that the module must be implemented to use its > > features, then I need to update some of my modules (e.g., crypto-types > > and friends) to explicitly disable the protocol-accessible tree when > > the module is implemented *only* to use its features. > > Since RFC 8525 doesn't allow a feature to be supported w/o also > implementing the module, I think this is the solution for now. And it > is not wrong even if RFC 8525 was updated to support features from > imported modules. > Deviation-stmts would be required to "undo" the base module implementation requirement. Looks like RFC 7895 got this part right. The 'feature' leaf-list may apply to imported modules. The same feature can only appear once, no matter how many revisions of a module are imported. Andy > > > 3) I wish more modules would following the pattern of having the > > global protocol accessible tree be defined via a "uses" of a grouping > > defined in the module. In another recent project, I had to hack the > > topology modules defined in RFC 8345 (to convert the containers to > > groupings) to enable a multiplicity of "abstract network topologies" > > to be configured. The assumption that only a single global instance > > is ever needed is proving to be invalid in my work time and again. > > This is a classic problem w/ any model... And you can extend it to > other things as well, not only top-level nodes; whenever you define a > leaf, perhaps someone could support multiple instances and wished it > was a leaf-list instead? And in a leaf-list, perhaps someone wanted > to add additional properites to each item, and wished it was a list > instead? And so on... > > > /martin > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
