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

[Lou Berger <[e-mail]>]

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