[netmod] handling module incompatibility

[Lou Berger <[e-mail]>]

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)