Hi, 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. In the subsequent discussion with the YANG Drs., the general discussion was heading down the path of using a new module name, and thereby not violating YANG module update rules. This lead us back to the a similar discussion we've been having in the context of 8022bis: how best to indicate that a whole module is being obsoleted. RFCs do this by adding 'metadata' to the headers, e.g., "Obsoletes: 8049", but this doesn't help YANG tooling. For 8022, we have one approach - publishing an updated rev of the original module marking all nodes as deprecated - but that doesn't really make sense for rfc8049bis. So the discussion for the WG is: How do we handle incompatible module changes, notably when one module 'obsoletes' another module -- from both the process and tooling perspectives? I know Benoit plans to bring in some thoughts/proposals, perhaps there are others. Cheers, Lou (as contributor/reviewer) _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
