On Fri, May 20, 2022 at 6:15 AM Kent Watsen <[email protected]> wrote:
> Martin, Andy, > > > 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. > > > I feel vindicated, but also feel that Martin is right about this being the > solution for now. I don't even feel that it is necessarily bad. But I do > think we should act on this in some way. Here are some options: > > 1) put a "document only" errata on RFC 8525. > 2) put a "document only" errata on RFC 7950. > 3) put a "document only" errata on RFC 8407. > 4) file a YANG Next issue. > 5) some combination of the above. > 6) anything else? > > I do not think an Errata can fix this issue because the split between 'module' and 'import-only-module' was intentional. Going back to iana-crypt-hash (again). - the features are not intended for use in any if-feature-stmts - each feature is related to one variant for values of the crypt-hash type Features are like identities. They are completely decoupled from the schema tree and simply use the parent module to create a unique QName for reference in other statements. Perhaps we should work on some proposed edits for yang-next. > Kent > Andy
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
