Re: [RTG-DIR] [netmod] handling module incompatibility

[Robert Wilton <[e-mail]>]

Hi,

On 06/10/2017 14:25, Lou Berger wrote:
> 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.

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.

Thanks,
Rob


>
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod