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

[Benoit Claise <[e-mail]>]

On 10/12/2017 3:30 PM, Benoit Claise wrote:
> 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.
See my message on this topic, as the IETF LC follow up.
https://www.ietf.org/mail-archive/web/ietf-announce/current/maillist.html
If a follow up is required, I propose that we use a single public email 
thread: the [e-mail]

Regards, Benoit
>
> 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)
>>>>
>>>>
>>>>
>>>>
>