Subject: [Netmod-ver-dt] definition of Non-Backwards-Compatible

From: "Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked]>
Date: Fri, 5 Oct 2018 13:51:23 +0000

Hi all,

Here is some proposed text to define non-backwards-compatible.

First of all let's agree on the exact terms we will use. I'd propose these (with hyphens, with an 's'):
  "backwards-compatible"
  "non-backwards-compatible"

https://semver.org/ has the term "backwards-compatible" in their summary.

Example in a sentence:  "Renaming a leaf is a non-backwards-compatible change."

Should we use "nbc" as a short form in any documents ? Probably not...

In the Requirements draft we should add a section called "Terminology" with the following proposed text:

--------------------------------------------------
The following terms are used within this document:

- non-backwards-compatible: In the context of this document, the term 'non-backwards-compatible' refers to a change or set of changes between two YANG modules that do not adhere to the list of allowable definition revisions specified in Section 11 "Updating a Module" of RFC7950, with the following exceptions and clarifications:
    - adding a "status" statement with a value of "obsolete", or changing a "status" statement from some other value to "obsolete", is considered a non-backwards-compatible change
    - the impact (to backwards-compatibility) of adding a "status" statement with a value of "deprecated", or changing a "status" statement from some other value to "deprecated" is TBD (future study ? depends on the server behavior ?).

-------------------------------------------------------------------------

Do we need to somehow specifically mention or refer to this paragraph from section 11 ? In theory it isn't in the "list of allowable definition revisions" (which is the bulleted list after the sentence that ends "... may be revised in any of the following ways:"):

    Otherwise, if the semantics of any previous definition are changed
   (i.e., if a non-editorial change is made to any definition other than
   those specifically allowed above), then this MUST be achieved by a
   new definition with a new identifier.

I was also wondering if we should say anything about the very last paragraph of section 11. I was surprised when I saw that reordering isn't allowed.  Does this mean you can't simply reorder 2 leafs ?

   In statements that have any data definition statements as
   substatements, those data definition substatements MUST NOT be
   reordered.  If new data definition statements are added, they can be
   added anywhere in the sequence of existing substatements.

Regards,
Jason

---

From: Joe Clarke <[email-masked]>
Date: Fri, 5 Oct 2018 09:58:39 -0400

On 10/5/18 09:51, Sterne, Jason (Nokia - CA/Ottawa) wrote:
> Should we use "nbc" as a short form in any documents ? Probably not…

Agreed.  I tried not to do it for so long, and then caved in.  I think
it's fine for intra-team communications.  We should expand in formal
documents.

> with the following proposed text:

Makes sense to me.

> - non-backwards-compatible: In the context of this document, the term
> 'non-backwards-compatible' refers to a change or set of changes between
> two YANG modules that do not adhere to the list of allowable definition
> revisions specified in Section 11 "Updating a Module" of RFC7950, with
> the following exceptions and clarifications:
> 
>     - adding a "status" statement with a value of "obsolete", or
> changing a "status" statement from some other value to "obsolete", is
> considered a non-backwards-compatible change
> 
>     - the impact (to backwards-compatibility) of adding a "status"
> statement with a value of "deprecated", or changing a "status" statement
> from some other value to "deprecated" is TBD (future study ? depends on
> the server behavior ?).

Do we want to add exceptions here in a requirements draft that defines
terminology?  I would think we'd just stick with your main paragraph.

The clacla draft does introduce the exceptions you raise, which I think
are more appropriate for a solution doc.

> Do we need to somehow specifically mention or refer to this paragraph
> from section 11 ? In theory it isn't in the "list of allowable
> definition revisions" (which is the bulleted list after the sentence
> that ends "… may be revised in any of the following ways:"):
> 
>  
> 
> I was also wondering if we should say anything about the very last
> paragraph of section 11. I was surprised when I saw that reordering
> isn't allowed.  Does this mean you can't simply reorder 2 leafs ?
> 
>  
> 

I think we can refer to section 11 without calling out any specific
parts of it.

Joe

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 5 Oct 2018 16:02:38 +0200

Why is "obsolete" settled to be non-backwards-compatible but "deprecated" is TBD? I agree that we need to clarify them but this kind of puts a specific solution already there, which I find surprising.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: "Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked]>
Date: Thu, 11 Oct 2018 13:52:39 +0000

Hi guys,

Joe raised a similar question about my exceptions.

If we define nbc purely by section 11 without exceptions, then it means someone can mark a leaf as 'obselete' and not increment the Major SemVer. I don't think we want that right ?

Jason

> -----Original Message-----
> From: Juergen Schoenwaelder <[email-masked]>
> Sent: Friday, October 5, 2018 10:03 AM
> To: Sterne, Jason (Nokia - CA/Ottawa) <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [Netmod-ver-dt] definition of Non-Backwards-Compatible
> 
> revisions specified in Section 11 "Updating a Module" of RFC7950, with the
> following exceptions and clarifications:
> >     - adding a "status" statement with a value of "obsolete", or changing a
> "status" statement from some other value to "obsolete", is considered a non-
> backwards-compatible change
> >     - the impact (to backwards-compatibility) of adding a "status" statement
> with a value of "deprecated", or changing a "status" statement from some
> other value to "deprecated" is TBD (future study ? depends on the server
> behavior ?).
> >
> Why is "obsolete" settled to be non-backwards-compatible but "deprecated"
> is TBD? I agree that we need to clarify them but this kind of puts a specific
> solution already there, which I find surprising.
> 
> /js
> 
> 
> --

---

From: Joe Clarke <[email-masked]>
Date: Thu, 11 Oct 2018 10:01:45 -0400

> If we define nbc purely by section 11 without exceptions, then it means someone can mark a leaf as 'obselete' and not increment the Major SemVer. I don't think we want that right ?

I think that instruction or guidance comes as part of the solution.  I
personally feel we want that, but I don't think it serves as a
definition to nbc.

Joe

> _______________________________________________
> Netmod-ver-dt mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod-ver-dt
>

---

From: "Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked]>
Date: Thu, 11 Oct 2018 15:01:56 +0000

OK. After discussions on the call today here is an updated definition proposal:

- non-backwards-compatible: In the context of this document, the term 'non-backwards-compatible' refers to a change or set of changes between two YANG modules that do not adhere to the list of allowable definition revisions specified in Section 11 "Updating a Module" of RFC7950, with the following exceptions and clarifications:
    - any addition of, or change to, a "status" statement that allows a server to remove support for a schema node, is considered a non-backwards-compatible change

Jason

> From: Joe Clarke <[email-masked]>
> Sent: Thursday, October 11, 2018 10:02 AM
> To: Sterne, Jason (Nokia - CA/Ottawa) <[email-masked]>; Juergen
> Schoenwaelder <[email-masked]>
> > If we define nbc purely by section 11 without exceptions, then it means
> someone can mark a leaf as 'obselete' and not increment the Major SemVer.
> I don't think we want that right ?
> 
> statement

---

From: Robert Wilton <[email-masked]>
Date: Thu, 11 Oct 2018 17:02:35 +0100

This looks fine to me.

I've also hopefully resolved my email issues (filtering rule bug in my 
client seemingly meant that the emails were being black holed!)

Thanks,
Rob

---

From: Balázs Lengyel <[email-masked]>
Date: Fri, 12 Oct 2018 15:49:04 +0000

Hello,

I love my abbreviations BC and NBC. non-backwards-compatible is 26 
characters nbc is 3. I will hate you each time I have to type it.
I see no anbiguity in using nbc.

regards Balazs

P.S. If I had a zip algorithm reaching that level of compression I would 
be a millionaire. I can save the world in all the time I spared :-)

On 2018. 10. 11. 18:02, Robert Wilton wrote:
>> 'non-backwards-compatible' refers to a change or set of changes 
>> between two YANG modules that do not adhere to the list of allowable 
>> definition revisions specified in Section 11 "Updating a Module" of 
>> RFC7950, with the following exceptions and clarifications:
>>      - any addition of, or change to, a "status" statement that 
>> allows a server to remove support for a schema node, is considered a 
>> non-backwards-compatible change
>>
>>>>>> changing a
>>>>> "status" statement from some other value to "obsolete", is 
>>>>> considered a
>>> non-

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: [email-masked]

---

From: Robert Wilton <[email-masked]>
Date: Fri, 12 Oct 2018 17:17:45 +0100

> I see no anbiguity in using nbc.
Using bc and nbc  is fine with me.  That is what I use in the solution 
comparison draft.

>
> regards Balazs
>
> P.S. If I had a zip algorithm reaching that level of compression I 
> would be a millionaire. I can save the world in all the time I spared :-)
cmix v16 compresses 1GB of text to 116MB.  Very close to your 
compression ratio of 26 down to 3, but it does take a week to run ;-)

Rob

>> I've also hopefully resolved my email issues (filtering rule bug in 
>> my client seemingly meant that the emails were being black holed!)
>>
>> Thanks,
>> Rob
>>
>>
>>> - non-backwards-compatible: In the context of this document, the 
>>> term 'non-backwards-compatible' refers to a change or set of changes 
>>>>>> between