Hi Andy, > 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.
My intention for using the "hold for document update" Errata (I wrote "document only" before) is only to better document the behavior that exists currently, so it doesn't have to be rediscovered again later. Martin pointed to an RFC section that didn't list features explicitly, leaving it open for interpretation. Patching such sections would be good. As for RFC 8407, maybe Section 4.17 (Feature Definitions) could say something? Following are a couple excerpts from https://www.ietf.org/about/groups/iesg/statements/processing-rfc-errata: Hold for Document Update - The erratum is not a necessary update to the RFC. However, any future update of the document might consider this erratum, and determine whether it is correct and merits including in the update. And (I added the underline): Changes which are simply stylistic issues or simply make things read better should be Hold for Document Update. Would you be willing to offer some text for an RFC 8407 "hold for document update" errata? If Martin does the same for the section he found, I think we would be covered. It seems is worthy effort, yes? Kent // contributor > > 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
