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

[Benoit Claise <[e-mail]>]

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


> Jürgen,
>
>> I do not understand the details why RFC 8049 is fundamentally
>> 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:
>>
>>    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.
> 8049 does not compile if you have a compiler that understands XPATH.
>
>> 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.
> 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
>
>
>> On Thu, Oct 05, 2017 at 03:41:28PM +0100, Adrian Farrel wrote:
>>> 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
>>>
>>>> -----Original Message-----
>>>> From: Juergen Schoenwaelder [mailto:[e-mail]]
>>>> Sent: 05 October 2017 15:07
>>>> To: Jan Lindblad
>>>> Cc: Lou Berger; YANG Doctors; [e-mail]
>>>> Subject: Re: [yang-doctors] Review of draft-wu-l3sm-rfc8049bis?
>>>>
>>>> On Thu, Oct 05, 2017 at 03:44:24PM +0200, Jan Lindblad wrote:
>>>>> 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.
>>>>
>>>> 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
>>>>
>>>>> /jan
>>>>>
>>>>>
>>>>>> On 10/5/2017 9:27 AM, Jan Lindblad wrote:
>>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> 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
>>>>>>>> _______________________________________________
>>>>>>>> yang-doctors mailing list
>>>>>>>> [e-mail]
>>>>>>>> https://www.ietf.org/mailman/listinfo/yang-doctors
>>>>> _______________________________________________
>>>>> yang-doctors mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/yang-doctors
>>>> --
>>>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>>>> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
>>>> Fax:   [phone]         <http://www.jacobs-university.de/>
>> -- 
>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
>> Fax:   [phone]         <http://www.jacobs-university.de/>
>>
> .
>