Subject: [yang-doctors] Review of draft-wu-l3sm-rfc8049bis?

From: Lou Berger <[email-masked]>
Date: Thu, 5 Oct 2017 09:10:09 -0400

Hi,

    Has there been a review conducted or is there one planned for
draft-wu-l3sm-rfc8049bis?  If not, I think one is needed.  I'm looking
at it now as part of RtgDir review and I believe some non-backwards
compatible changes in the defined yang module.

Thanks,
Lou

PS for module diffs see:
 
https://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-wu-l3sm-rfc8049bis-05.txt&url1=rfc8049

---

From: Jan Lindblad <[email-masked]>
Date: Thu, 5 Oct 2017 15:27:47 +0200

Lou,

I have reviewed the updated model from a YANG perspective. The old model contained syntax errors(!), so there was no way to (correctly) implement it. Hence I believe requirements on backwards compatibility should be treated lightly.

/jan

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

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 5 Oct 2017 14:37:40 +0100

Hello,

The changes in this bis largely arise from a review by Jan Lindblad who is one of the YAG Doctors.

You could say that what happened was that the YANG Doctor review for draft-ietf-l3sm-l3vpn-service-model came in a little behind schedule and so a bis was needed. Jan also brought some valuable implementation experience.

Now, you may have a slightly different concern. Specifically: is draft-wu-l3sm-rfc8049bis backward compatible with RFC 8049?

That was certainly not an objective that I was aware of. I think 8049 has only been out a short time and that implementations are "at an early stage." Indeed, as Jan points out, a correct implementation will *need* the fixes in this draft.

A

> -----Original Message-----
> From: Lou Berger [mailto:[email-masked]]
> Sent: 05 October 2017 14:10
> To: YANG Doctors
> Cc: [email-masked]
> Subject: Review of draft-wu-l3sm-rfc8049bis?
> 
> Hi,
>

---

From: Lou Berger <[email-masked]>
Date: Thu, 5 Oct 2017 09:39:22 -0400

Jan,

What about the type changes (int32->int64, int->string)?

Thanks,
Lou

---

From: Lou Berger <[email-masked]>
Date: Thu, 5 Oct 2017 09:45:09 -0400

Adrian,

Thanks for the background.  We have a somewhat similar situation going
on right now with rfc 8022 (been out a short time, no shipping
implementations, *but* update motivated by need to be updated to NMDA
compatible form).  In that case, we're headed down a path of deprecating
the old modules and issuing a replacement '-2' version.  Would it make
sense to do a similar thing here and just rename the module (to
ietf-l3vpn-svc-2) and thereby conform with YANGs compatibility requirement?

Lou

---

From: Jan Lindblad <[email-masked]>
Date: Thu, 5 Oct 2017 15:44:24 +0200

Lou,

> What about the type changes (int32->int64,

This is a backwards compatible change according to both 6020 and 7950.

> int->string)?

Even if a type change int->str might qualify as "backwards compatible" according to 6020 and 7950, the particular change at hand is not because of considerable changes in semantics.

/jan

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 5 Oct 2017 14:56:09 +0100

> ietf-l3vpn-svc-2) and thereby conform with YANGs compatibility requirement?

I have no strong opinion either way.

Given that 8049 can't be implemented, I'm not sure that the module it specifies actually exists at all.

I'm really happy to be guided by anyone who does have a strong opinion.

A

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 5 Oct 2017 16:07:09 +0200

> Even if a type change int->str might qualify as "backwards compatible" according to 6020 and 7950, the particular change at hand is not because of considerable changes in semantics.

I think both type changes are problematic. RFC 7950 says:

   o  A "type" statement may be replaced with another "type" statement
      that does not change the syntax or semantics of the type.  For
      example, an inline type definition may be replaced with a typedef,
      but an int8 type cannot be replaced by an int16, since the syntax
      would change.

/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: Lou Berger <[email-masked]>
Date: Thu, 5 Oct 2017 10:35:18 -0400

> I'm really happy to be guided by anyone who does have a strong opinion.

I don't have a strong opinion, but am concerned about the precedent it
establishes WRT how we handle other incompatible module changes.  If we
open the door on this change, what was a hard rule becomes
subjective/open to interpretation...

Lou

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 5 Oct 2017 15:41:28 +0100

Pardon me for asking for some help getting this straight in my head.

When we move from one version of an I-D to another, we don't pay any attention
to backward compatibility.

When we revise an established module we must be backward compatible to allow the
new version to be inserted without damaging existing implementations, or we must
call the module something new to avoid confusion.

When we have a module that cannot be implemented (because it is broken) and that
is being fixed through the obsoleting of an RFC, do we *really* care about
backward compatibility? If we do care, then the answer is simple: we revise the
module name, etc. If the issue isn't a big deal, we go ahead as written.

Thanks,
Adrian

> From: Juergen Schoenwaelder [mailto:[email-masked]]
> Sent: 05 October 2017 15:07
> To: Jan Lindblad
> Cc: Lou Berger; YANG Doctors; [email-masked]
> Subject: Re: [yang-doctors] Review of draft-wu-l3sm-rfc8049bis?
> 
> > Even if a type change int->str might qualify as "backwards compatible"
> according to 6020 and 7950, the particular change at hand is not because of
> considerable changes in semantics.
> 
> > >> I have reviewed the updated model from a YANG perspective. The old
> model contained syntax errors(!), so there was no way to (correctly) implement
> it. Hence I believe requirements on backwards compatibility should be treated
> lightly.
> > >>
> > >> /jan
> > >>
> > >>
> > >>
> > >>> Hi,
> > >>>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 5 Oct 2017 18:10:39 +0200

Adrian,

I do not understand the details why RFC 8049 is fundamentally
broken. The abstract of the ID says:

   If approved, this document obsoletes RFC 8049.  The changes are a
   series of small fixes to the YANG module, and some clarifications to
   the text.

This does not read like fundamentally flawed and not implementable.
That said, I did react to Jan's statement that kind of indicated that
these changes are generally OK - which I think they are not.

If this document chooses to not follow the YANG update rules, I think
this should be supported by a clear documentation why this is
considered to be OK, somewhere in the document.

/js

---

From: Jan Lindblad <[email-masked]>
Date: Fri, 6 Oct 2017 08:55:37 +0200

Jürgen,

> broken.

The 8049 YANG model had broken XPATH expressions, so a compliant implementation was impossible. The qos rules architecture was at odds with other IETF models, e.g. the ACL model. I would actually call this out as a bigger problem than the former. Then, there were some minor description enhancements, added defaults and adjustments of types.

> The abstract of the ID says:
> 

8049 does not compile if you have a compiler that understands XPATH.

> considered to be OK, somewhere in the document.

I never pretended the new module would be backwards compatible with 8049. The specific element I mentioned as being individually backwards compatible, is not according to section 11 in 7950. Thanks for clarifying that. 

Maybe what we should do to respect section 11 rules, and give a clear message to implementors, is to give the module a new namespace and name.

/jan

---

From: Benoit Claise <[email-masked]>
Date: Fri, 6 Oct 2017 14:40:12 +0200

Dear all,

The big problem: RFC8049 is broken
The small problem: trying to maintain backward compatibility.

draft-wu-l3sm-rfc8049bis has rightly focused on the big problem.

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. The lack of 
responses might be perceived as the IETF community not being ready for 
this discussion.

The point is that we need, in 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 module.

Two solutions:
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

       // 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.";
          }

2. Or we have a different module name, let's say ietf-l3vpn-svc-2.
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?

    <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 ietf-l3vpn-svc@2017-01-2

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, but this is just an 
offline trick.
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";

Maybe we should discuss this on the NETMOD mailing list in the end, for 
a longer term solution. Thoughts?
However, let's not block the RFC8049bis and RFC8022bis publications at 
this point in time.

Regards, Benoit

> .

---

From: Lou Berger <[email-masked]>
Date: Fri, 6 Oct 2017 08:48:12 -0400

Benoit,
	
I agree this we should move this to netmod WG list.  Do you want to kick
it off or should I?

Another alternative that doesn't modify existing versioning rules is to
(a) rename the module and (b) add the "obsolete" statement to indicate
that the -N version replaces the N-1 version.

Lou

On 10/06/2017 08:40 AM, Benoit Claise wrote:
>        "First revision of RFC8049 <https://tools.ietf.org/html/rfc8049>.";
>       reference

---

From: Benoit Claise <[email-masked]>
Date: Fri, 6 Oct 2017 14:55:26 +0200

Lou,
> I agree this we should move this to netmod WG list.  Do you want to kick
Ok, I'll do it (most probably on Monday)
> that the -N version replaces the N-1 version.
Like what I proposed below? This would be a new YANG statement.

     <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 *ietf-l3vpn-svc@2017-01-2

Note also that draft-claise-semver was also an attempt at solving the 
semantic versioning issue.

Regards, Benoit

---

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

> Ok, I'll do it (most probably on Monday)
okay, I can send something to day that gives the 8049 specific context.

> Like what I proposed below? 
well, a variant of it. 

> This would be a new YANG statement.
the difference is I'd change the name as well, e.g., ietf-l3vpn-svc-2

> semantic versioning issue.
Understood.

Lou