Kent Watsen <[email protected]> writes: > 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
But the alternative behaviour exists as well. I don't think this can be fixed by an erratum. Lada > 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 -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
