>> As part of the my Routing Directorate review of >> draft-wu-l3sm-rfc8049bis I noted that there were several incompatible >> changes being made to the ietf-l3vpn-svc module without changing the >> name. I raised this with the YANG doctors and others involved with the >> draft and it surfaced some topics which really should be discussed here >> in NetMod. >> >> The background (as explained off-list by others, so I hope I have it >> right) is that one of the YANG Doctors noted that RFC8049 was broken >> and could not be implemented as defined, and therefore a fix was >> needed. L3SM has concluded so the fix is in the individual draft >> draft-wu-l3sm-rfc8049bis. Since the rfc8049 version of ietf-l3vpn-svc >> module could not be implemented, the feeling by the YANG Dr was that >> even though the new module is incompatible with the original definition >> the module the rule defined in Section 11 of YANG 1.1 (or section 10 of >> RFC 6020) didn't have to be followed and the same name could be used. > >I think that this is the view that I support as well. If something is >clearly broken then it should be possible to fix it without requiring a >new module name, just an updated revision. > >Once the modules are properly stable, have multiple implementations, >then I fully support the 7950 update guidelines, but I think that they >are a bit strict as IETF is developing brand new modules, particularly >those that don't necessarily have implementations behind them at the >point that they reach RFC.
I agree with allowing a do-over using the same module name. With regards to how to indicate that an entire module is obsolete, I added this entry to the yang-next tracker a while ago: https://github.com/netmod-wg/yang-next/issues/28. K. // contributor _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
