Re: [netmod] handling module incompatibility

["t.petch" <[e-mail]>]

----- Original Message -----
From: "Lou Berger" <[e-mail]>
Sent: Friday, October 06, 2017 2:25 PM

> 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?

Add a new substatement to the module statement, 'obsoletes' or
'supersedes'or such like..

And I mean write the RFC now, do not wait for a future version or
revision of RFC7950.

Tom Petch

> I know Benoit plans to bring in some thoughts/proposals, perhaps there
> are others.
>
> Cheers,
>
> Lou
>
> (as contributor/reviewer)
>
>