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

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