Re: [netmod] [RTG-DIR] handling module incompatibility => handling module transition

[Benoit Claise <[e-mail]>]

Hi Lou,
>
> So circling back to the original question: what do we do about the non 
> backward-compatible module being defined in rfc8049bis?
>
> While being sympathetic to many of the comments made below as well as 
> the "do over" concept, I find the comments about adhering to the rules 
> of 7950 compelling - which leads to renaming the module in the bis to 
> ietf-l3vpn-svc-2.
>
> It would be good to ensure that this is the consensus of the group 
> before asking the authors make this change.
>
Since this draft is AD sponsored, I'll evaluate the consensus on RFC8049bis.
Moving to ietf-l3vpn-svc-2 is the easy path not to break backward 
compatibility. However, since ietf-l3vpn-svc is unimplementable (it has 
broken XPATH expressions, so a compliant implementation is impossible), 
so technically, ietf-l3vpn-svc does not even exist.

What NETMOD should focus on is closing on the NMDA transition: the 
ietf-routing versus ietf-routing-2 issue.
Way bigger impact in terms of dependent YANG modules

Regards, Benoit (as OPS AD)
See below.
>
> This change course doesn't solve the versioning issue discussed below, 
> but this is not a new issue it's just the first time we'll actually 
> executing the steps envisioned as part of the rules laid out in yang. 
> My personal take away is that means that we should immediately start 
> work on an extension defining along the lines of  ' 
> *_obsolete|update_*' mentioned below.
>
I believe that option 1 is the more pragmatic and complete solution. 
option 2 is just half a step in the right direction.
I believe we should discuss this topic in Singapore.

Regards, Benoit (as individual contributor)
>
> Lou
>
> On October 8, 2017 10:59:15 AM Benoit Claise <[e-mail]> wrote:
>
>> Dear all,
>>
>> Focusing on draft-wu-l3sm-rfc8049bis, the big problem is: RFC8049 is 
>> broken. The small problem is: trying to maintain backward compatibility.
>> draft-wu-l3sm-rfc8049bis has rightly focused on the big problem.
>>
>> Let me extend the scope of this email thread from "handling module 
>> incompatibility" to "handling module incompatibility and NMDA 
>> transition".
>> As I mentioned in the past (see "semver.org comparison of two YANG 
>> modules" email in NETMOD), I believe the IETF will have to change its 
>> way of working in terms of backward compatibility. See also the email 
>> "ietf-routing or ietf-routing-2? module naming convention for NMDA 
>> transition. Re: [netmod] upcoming adoptions" in NETMOD.
>>
>> However, we will have to tackle this discussion one day or the other:
>> - we need _an automatic way_ to make the link between the YANG module 
>> in RFC8049 and the YANG module in draft-wu-l3sm-rfc8049bis, or any 
>> non backward compatible YANG modules.
>> - we need _an automatic way_ to make the link between the YANG module 
>> in RFC8022 and the YANG module in draft-acee-netmod-rfc8022bis, or 
>> any new YANG module names used for NMDA transition.
>> Note: actually, we face two different problems. 
>> draft-wu-l3sm-rfc8049bis might be declared backward incompatible with 
>> RFC8049, while RFC8022bis is backward compatible with RFC8022. The 
>> RFC8022bis went for a new YANG module name ietf-routing-2 to avoid to 
>> document the -state tree (as deprecated), based on the argument that 
>> ietf-routing is not yet implemented.
>>
>> Which solutions do we have from here?
>> #1. We keep the same module name and express that the YANG module in 
>> draft-wu-l3sm-rfc8049bis is not backward compatible with the RFC8049 
>> one. This is the openconfig way. See 
>> draft-clacla-netmod-model-catalog (and 
>> draft-openconfig-netmod-model-catalog before)
>>
>>        // extension statements
>>           extension openconfig-version {
>>             argument "semver" {
>>               yin-element false;
>>             }
>>             description
>>               "The OpenConfig version number for the module. This is
>>               expressed as a semantic version number of the form:
>>                 x.y.z
>>                where:
>>                 * x corresponds to the major version,
>>                 * y corresponds to a minor version,
>>                 * z corresponds to a patch version.
>>               This version corresponds to the model file within which it is
>>               defined, and does not cover the whole set of OpenConfig models.
>>               Where several modules are used to build up a single block of
>>               functionality, the same module version is specified across each
>>               file that makes up the module.
>>
>>               A major version number of 0 indicates that this model is still
>>               in development (whether within OpenConfig or with industry
>>               partners), and is potentially subject to change.
>>
>>               Following a release of major version 1, all modules will
>>               increment major revision number where backwards incompatible
>>               changes to the model are made.
>>
>>               The minor version is changed when features are added to the
>>               model that do not impact current clients use of the model.
>>
>>               The patch-level version is incremented when non-feature changes
>>               (such as bugfixes or clarifications to human-readable
>>               descriptions that do not impact model functionality) are made
>>               that maintain backwards compatibility.
>>
>>               The version number is stored in the module meta-data.";
>>           }
>>
>> Similarly, we always keep the same YANG module name in case of NMDA 
>> transition. So ietf-routing-2 should be changed back to ietf-routing.
>> The email thread "[Rtg-dt-yang-arch] ietf-routing or ietf-routing-2? 
>> module naming convention for NMDA transition. Re: [netmod] upcoming 
>> adoptions" seems to go in that direction.
>>
>> #2. Or we have a different module name, let's say ietf-l3vpn-svc-2 or 
>> ietf-routing-2 but then, how do we make the link with the previous 
>> module?
>> Then ...  What? We create extension that will link the 
>> draft-wu-l3sm-rfc8049bis YANG module to the RFC8049 YANG module? Same 
>> principle as #1, but just more complex.
>> Or we have a new YANG keyword (this implies YANG 2.0)
>>
>>     <CODE BEGINS>file"[e-mail]"
>>     module ietf-l3vpn-svc-2 {
>>       yang-version 1.1;
>>       namespace "urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc";
>>       prefix l3vpn-svc;
>>       *_obsolete|update _*ietf-l3vpn-svc@2017-01-2
>>
>> And whose responsibility is this to warn/push all authors of 
>> ietf-routing YANG modules to move to ietf-routing-2? (*)
>>
>> The following are non solution IMO:
>> - Going from the draft-wu-l3sm-rfc8049bis YANG _module _to the 
>> draft-wu-l3sm-rfc8049bis _document _to lookup the IETF "obsolete" 
>> flag in order to understand that the RFC8049 YANG module is obsolete 
>> is not an automatic solution.
>> - Using the yangcatalog.org might be a solution as we track the 
>> derived semantic, but this is just an offline trick. This is not what 
>> I call "automatic way"
>> - Using the YANG module description field might be interesting, but 
>> again this is not an "automatic way":
>>
>>       description
>>        "This YANG module defines a generic service configuration
>>         model for Layer 3 VPNs. This model is common across all
>>         vendor implementations. This obsoletes the RFC8049 YANG
>>         module, ietf-l3vpn-svc@2017-01-2";
>>       revision 2017-09-14 {
>>        description
>>        
>>     "First revision ofRFC8049 <https://tools.ietf.org/html/rfc8049>.";
>>        reference
>>         "RFC xxxx: YANG Data Model for L3VPN Service Delivery";
>>
>>
>> In conclusion, I believe openconfig got this right and that solution 
>> #1 is the solution to go ... while waiting for a new YANG keyword in 
>> YANG 2.0
>>
>> (*) If you want to change the module from ietf-routing to 
>> ietf-routing-2, then you should follow with all authors of dependent 
>> modules to make sure they transition to ietf-routing-2
>> In the yangcatalog.org, because I needed the information as OPS AD, 
>> we created a small script to get that authors list for IETF drafts. 
>> For the ietf-routing, this produces the following
>> {
>>     "output": {
>>         "author-email": [
>> "[e-mail]",
>> "[e-mail]",
>> "[e-mail]",
>> "[e-mail]",
>> "[e-mail]",
>> "[e-mail]",
>> "[e-mail]",
>> "[e-mail]",
>> "[e-mail]",
>> "[e-mail]",
>> "[e-mail]",
>> "[e-mail]",
>> "[e-mail]",
>> "[e-mail]",
>> "[e-mail]",
>> "[e-mail]",
>> "[e-mail]",
>> "[e-mail]",
>> "[e-mail]",
>> "[e-mail]",
>> "[e-mail]",
>> "[e-mail]"
>>         ]
>>     }
>> }
>>
>> Fortunately, we only deal with IETF dependent YANG modules in case of 
>> the ietf-routing. That's an easier case.
>> If we would change ietf-interfaces to ietf-interfaces-2, we would 
>> have an cross SDO issue ... Btw, there are no automatic ways to 
>> extract the authors of YANG modules from different SDOs: it's only a 
>> metadata that that the different SDOs should insert in the 
>> yangcatalog. So we would have to rely on liaisons or direct emails, 
>> assuming we know the authors. Time consuming, believe me.
>>
>> Regards, Benoit
>>> 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)
>>>
>>>
>>>
>>>