Subject: [netmod] handling module incompatibility

From: Lou Berger <[email-masked]>
Date: Fri, 6 Oct 2017 09:25:37 -0400

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)

---

From: Robert Wilton <[email-masked]>
Date: Fri, 6 Oct 2017 15:49:50 +0100

Hi,

> 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

> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

---

From: Kent Watsen <[email-masked]>
Date: Fri, 6 Oct 2017 15:05:24 +0000

>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

---

From: "t.petch" <[email-masked]>
Date: Fri, 6 Oct 2017 17:34:05 +0100

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

> 'obsoletes' another module -- from both the process and tooling

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 6 Oct 2017 18:53:42 +0200

On Fri, Oct 06, 2017 at 03:49:50PM +0100, Robert Wilton wrote:
> clearly broken then it should be possible to fix it without requiring a new
> module name, just an updated revision.
>

The hidden question is what is 'broken' or 'clearly broken' and when
are definitions in a module broken and when is the damage so big that
the whole module is broken. Does a broken xpath statement cause the
whole module to be fundamentally flawed such that an implementation of
the rest is impossible?

It is not uncommon to find errors in data models and it is then often
a matter of a new revision or errata to address those. The question
here is when is an entire module broken up to the point that nobody
ever will have implemented it or parts of it.

I do not know the answer but I see a certain risk that minor bugs will
be used to argue none of the YANG update rules apply.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Benoit Claise <[email-masked]>
Date: Sun, 8 Oct 2017 16:58:32 +0200

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"[email-masked]"
    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": [
"[email-masked]",
"[email-masked]",
"[email-masked]",
"[email-masked]",
"[email-masked]",
"[email-masked]",
"[email-masked]",
"[email-masked]",
"[email-masked]",
"[email-masked]",
"[email-masked]",
"[email-masked]",
"[email-masked]",
"[email-masked]",
"[email-masked]",
"[email-masked]",
"[email-masked]",
"[email-masked]",
"[email-masked]",
"[email-masked]",
"[email-masked]",
"[email-masked]"
         ]
     }
}

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

---

From: Lou Berger <[email-masked]>
Date: Thu, 12 Oct 2017 07:33:04 -0400

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.

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.

Lou

---

From: Benoit Claise <[email-masked]>
Date: Thu, 12 Oct 2017 15:30:09 +0200

Hi Lou,
> 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)
>> - 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.
>>
>> one. This is the openconfig way. See 
>> draft-clacla-netmod-model-catalog (and 
>> draft-openconfig-netmod-model-catalog before)
>>
>>        // extension statements
>> 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"
>> 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
>>
>> 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": [
>> 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,
>>>

---

From: Qin Wu <[email-masked]>
Date: Fri, 13 Oct 2017 01:30:24 +0000

Thank Lou to help bring up this issue, thank Robert, Juergen, Tom, Kent to share your valuable thoughts.
Jurgen, we will address your concern in v-(07) based on your input and others' feedback.
Many thanks.

-Qin
-----邮件原件-----
发件人: Juergen Schoenwaelder [mailto:[email-masked]] 
发送时间: 2017年10月7日 0:54
收件人: Robert Wilton
抄送: Lou Berger; NetMod WG; [email-masked]; [email-masked]
主题: Re: [netmod] handling module incompatibility

On Fri, Oct 06, 2017 at 03:49:50PM +0100, Robert Wilton wrote:
> > 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.
> > 
> > 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.
> 
> clearly broken then it should be possible to fix it without requiring 
> a new module name, just an updated revision.
>

The hidden question is what is 'broken' or 'clearly broken' and when are definitions in a module broken and when is the damage so big that the whole module is broken. Does a broken xpath statement cause the whole module to be fundamentally flawed such that an implementation of the rest is impossible?

It is not uncommon to find errors in data models and it is then often a matter of a new revision or errata to address those. The question here is when is an entire module broken up to the point that nobody ever will have implemented it or parts of it.

I do not know the answer but I see a certain risk that minor bugs will be used to argue none of the YANG update rules apply.

/js

---

From: Benoit Claise <[email-masked]>
Date: Sun, 15 Oct 2017 18:26:35 +0200

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?
>>
>> 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.
>>
> 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 [email-masked]

Regards, Benoit
>> 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  ' 
>>> 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.
>>>
>>> - 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.
>>> 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.
>>>
>>> #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?
>>> draft-wu-l3sm-rfc8049bis YANG module to the RFC8049 YANG module? 
>>> Same principle as #1, but just more complex.
>>> derived semantic, but this is just an offline trick. This is not 
>>> what I call "automatic way"
>>> Fortunately, we only deal with IETF dependent YANG modules in case 
>>> of the ietf-routing. That's an easier case.