Re: [netmod] handling module incompatibility

[Kent Watsen <[e-mail]>]

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