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

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:j.schoenwaelder@jacobs-university.de]
>>> Sent: 05 October 2017 15:07
>>> To: Jan Lindblad
>>> Cc: Lou Berger; YANG Doctors; draft-wu-l3sm-rfc8049bis.all@ietf.org
>>> 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
>>>>>>> yang-doctors@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/yang-doctors
>>>>>> 
>>>>> 
>>>> 
>>>> _______________________________________________
>>>> yang-doctors mailing list
>>>> yang-doctors@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/yang-doctors
>>> 
>>> --
>>> 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/>
>> 
> 
> -- 
> 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/>
> 