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

[Lou Berger <[e-mail]>]

On 10/6/2017 8:55 AM, Benoit Claise wrote:
> Lou,
>> Benoit,
>> 	
>> I agree this we should move this to netmod WG list.  Do you want to kick
>> it off or should I?
> Ok, I'll do it (most probably on Monday)
okay, I can send something to day that gives the 8049 specific context.

>> 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.
> Like what I proposed below? 
well, a variant of it. 

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

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

Lou
> Regards, Benoit
>> Lou
>>
>>
>> On 10/06/2017 08:40 AM, Benoit Claise wrote:
>>> 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 of RFC8049 <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/>
>>>>>
>>>> .
>>>>
>> .
>>
>