Subject: [Netmod-ver-dt] first attempt at a concise problem statement

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 21 Jun 2018 17:45:33 +0200

Hi,

here is how I would write the problem statement in a much more concise
way. This avoids getting side tracked in discussions about examples
being right or wrong (I disagree with the 355 pattern example for
instance, I believe you can do this bug fix even today if the
description says this is an IPv4 address).

* Problem Statement

  Development of data models for a large collection of communication
  protocols and system components is difficult and typically only
  manageable with an iterative development process. Agile development
  approaches advocate evolutionary development, early delivery, and
  continual improvement. They are designed to support rapid and
  flexible response to change. Agile development has been found to be
  very successful in a world where the objects being modeled undergo
  constant changes.

  The current module versioning scheme relies on the fundamental idea
  that a definition, once published, never changes its semantics. As a
  consequence, if a new definition is needed with different
  non-backwards compatible semantics, then a new definitions must be
  created to replace the old definition. The advantage of this
  versioning scheme is that a definition identified by a module name
  and a path has fixed semantics that never change. (The details are a
  bit more nuanced but we simplify things here a bit in order to get
  the problems worked out clearly.)

  There are two main disadvantages of the current YANG versioning
  scheme:

  - Any non-backwards compatible change of a definition requires
    either a new module name or a new path. This has been found costly
    to support in implementations, in particular on the client side.

  - Since non-backwards compatible changes require either a new module
    name or a new path, such changes will impact other modules that
    import definitions. In fact, with the current module versioning
    scheme other modules have to opt-in in order to use the new
    version. This essentially leads to a ripple effect where a
    non-backwards compatible change of a core module causes updates on
    a potentially large number of dependent modules.

  Other problems experienced with the current YANG versioning scheme
  are the following:

  - YANG has a mechanism to mark definitions deprecated but it leaves
    it open whether implementations are expected to implement
    deprecated definitions and there is no way (other than trial and
    error) for a client to find out whether deprecated definitions are
    supported by a given implementation.

  - YANG does not have a robust mechanism to document which data
    definitions have changed and to provide guidance how
    implementations should deal with the change. While it is possible
    to have this described in general description statements, having
    these details embedded in general description statements does not
    make this information accessible to tools.

  - YANG data models often do not exist in isolation and they interact
    with other software systems or data models that often do allow
    (controlled) non-backwards compatible changes. In some cases, YANG
    models are even derived from other data models that do allow
    (controlled) non-backwards compatible changes. In such situations,
    a robust mapping to YANG requires to have version numbers exposed
    as part of the module name or a path definition, which has been
    found to be expensive on the client side (see above).

  Given the need to support agile development processes and the
  disadvantages and problems of the current YANG versioning scheme
  described above, it is necessary to develop requirements and
  solutions for a future YANG versioning scheme that better supports
  agile development processes.

/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: Balazs Lengyel <[email-masked]>
Date: Fri, 22 Jun 2018 12:41:47 +0200

Hello,

IMHO Jurgen's text is speaking in very general terms. For me it is 
easier to understand specific problems.
This is especially true for the paragraph starting with "YANG does not 
have a robust mechanism to ..."

Also the following issues are not mentioned as I see it:

- removal or obsoletion of old/bad/unused model parts can only be done by
either violating today's assumption about keeping module revisions 
compatible
or following the expensive procedure of renaming the module.

- No good way to specify which module revision to import. The problem 
here is
not that versioning is good or bad, rather we need a more advanced way to
specify which versions can be imported.

- Early Warning about Removal is needed

- the current fundamental idea  that a definition, once published, never 
changes its semantics is not valid because removing the implementation 
behind deprecated and obsolete schema nodes violates it.

regards Balazs

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

---

From: Robert Wilton <[email-masked]>
Date: Fri, 22 Jun 2018 11:56:26 +0100

So, I do like the fact the Juergen's text is concise, it feels like it 
provides a concise summary of problem (although as you say it may not be 
complete).

However, Balazs, I do agree with you that often it can be helpful, at 
least for readers who are less familiar with the problem domain, to 
understand concrete cases/examples.

Do you think it would be plausible to combine the two?

E.g. Start the problem section with Juergen's more abstract 
summary/overview, but then follow that up with the specific more 
concrete problem definitions that we have at the moment (obviously, some 
overlap/duplication would need to be removed).

Thanks,
Rob

On 22/06/2018 11:41, Balazs Lengyel wrote:
> - the current fundamental idea  that a definition, once published, 
> never changes its semantics is not valid because removing the 
> implementation behind deprecated and obsolete schema nodes violates it.
>
> regards Balazs
>

---

From: Balazs Lengyel <[email-masked]>
Date: Fri, 22 Jun 2018 13:02:41 +0200

Yes, I can agree with the combination: Having some text like Jurgen's 
and then specific issues.

However I consider the current violation of  assumed backwards 
compatibility using deprecated/obsolete as part of the basic problem. It 
indicates that we are not just trying to redesign this to make it 
better. It indicates that the current system is broken, so something 
must be done.

Balazs

On 6/22/2018 12:56 PM, Robert Wilton wrote:
> provides a concise summary of problem (although as you say it may not 
> be complete).
>
> concrete problem definitions that we have at the moment (obviously, 
> some overlap/duplication would need to be removed).
>
>
>
>> This is especially true for the paragraph starting with "YANG does 
>> not have a robust mechanism to ..."
>>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 22 Jun 2018 13:25:08 +0200

On Fri, Jun 22, 2018 at 01:02:41PM +0200, Balazs Lengyel wrote:
> 
> However I consider the current violation of  assumed backwards compatibility
> using deprecated/obsolete as part of the basic problem. It indicates that we
> are not just trying to redesign this to make it better. It indicates that
> the current system is broken, so something must be done.
>

I strongly disagree with this statement.

/js

---

From: Lou Berger <[email-masked]>
Date: Fri, 22 Jun 2018 08:50:14 -0400

Juergen,

     Nice summary!  On comment - this misses that servers are currently 
limited to supporting a single version of a module, and that there is a 
need to preserve (or provide, depending on your perspective) backwards 
compatibility for older/deployed clients. To me this is a critical 
aspect that must be addressed as part of any solution addressing this 
problem.

Lou

---

From: Robert Wilton <[email-masked]>
Date: Fri, 22 Jun 2018 16:22:55 +0100

Hi Balazs,

One other suggestion on how to merge this.

We could put the existing problem definition text into the background 
section that I've added, and then use something like Juergen's text in 
the Problem Statement (extended to ensure that it is complete).

This might make it easier for readers that are less familiar with the 
problem, they see the concrete examples of the problem, but also ends up 
with a concise problem statement.

What do you think?

Thanks,
Rob

On 22/06/2018 12:02, Balazs Lengyel wrote:
> compatibility using deprecated/obsolete as part of the basic problem. 
> It indicates that we are not just trying to redesign this to make it 
>> So, I do like the fact the Juergen's text is concise, it feels like 
>> it provides a concise summary of problem (although as you say it may 
>> not be complete).
>>
>>> - No good way to specify which module revision to import. The 
>>> problem here is

---

From: Balazs Lengyel <[email-masked]>
Date: Fri, 22 Jun 2018 17:31:49 +0200

If we keep the current detailed problem list I am happy with this. 
However if Jurgen can make his text a bit more concrete, more specific 
that would be good. (I will not object if it stays as is.)

Balazs

On 6/22/2018 5:22 PM, Robert Wilton wrote:
> problem, they see the concrete examples of the problem, but also ends 
> up with a concise problem statement.
>
> What do you think?
>
> Thanks,
> Rob
>
>
>>> However, Balazs, I do agree with you that often it can be helpful, 
>>> at least for readers who are less familiar with the problem domain, 
>>> to understand concrete cases/examples.
>>>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 22 Jun 2018 19:31:24 +0200

On Fri, Jun 22, 2018 at 04:22:55PM +0100, Robert Wilton wrote:
> section that I've added, and then use something like Juergen's text in the
> Problem Statement (extended to ensure that it is complete).

The current text is partially broken from my point of view. The
pattern example is likely nonsense or at least too imcomplete to make
sense. I do not like the standardization is slow start - there is no
evidence that a different versioning scheme will change the speed in
which people find consensus and run documents through the whole
process. If we keep the current text, we have to invest time. If all
this is thrown away anyway, there is no point in working on this.

Alternative: Include a concise definition of the problem and refer to
other documents for examples / history. If all these documents go
nowhere, this is as good as copying text describing examples.

/js

---

From: Benoit Claise <[email-masked]>
Date: Fri, 22 Jun 2018 12:53:39 -0700

> Do you think it would be plausible to combine the two?
That would be ideal.
For example,

         (controlled) non-backwards compatible changes.

I believe you have in mind generated YANG models, but I'm not sure.

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 24 Jun 2018 10:35:01 +0200

> I believe you have in mind generated YANG models, but I'm not sure.

I am not saying the wording is perfect but it says "YANG models are
even derived from other data models".

/js

---

From: Robert Wilton <[email-masked]>
Date: Wed, 27 Jun 2018 15:42:34 +0100

> this is thrown away anyway, there is no point in working on this.
OK, but I do think that it is fact that standardization has been slow, 
whether this is during to versioning, or trying to reach consensus is 
unclear to me.  Certainly the OpenConfig models have managed to move 
much faster.

At the moment, I think that we just need to get an initial draft of the 
requirements document out of the door before the end of the week.  As 
you say, it is not clear where this document will end up, and spending 
lots of time on this now probably doesn't help.

To that end:
  1) I've moved the existing problem statements into the background section.
  2) I've renamed "Slow Standardization" to "Striving for model perfection".
  3) I've changed the last sentence of the "non backwards compatible bug 
fix" from "Still current YANG rules would force a module name change." 
to "Current YANG rules are ambiguous as to whether non backwards 
compatible bug fixes are allowed without also requiring a module name 
change."
4) I've added Juergen's text as the problem definition.
5) I've tweaked the wording of Juergen's problem definition from "In 
some cases, YANG models are even derived from other data models that do 
allow (controlled) non-backwards compatible changes." to "In some cases, 
YANG models are mechanically derived from other data models that do 
allow (controlled) non-backwards compatible changes."
6) I've added an extra clause to the last paragraph of the problem 
definition (to address Lou's comment): "

    Given the need to support agile development processes and the
    disadvantages and problems of the current YANG versioning scheme
    described above, it is necessary to develop requirements and
    solutions for a future YANG versioning scheme that better supports
    agile development processes,*whilst retaining the ability for servers to support clients using older 
versions of YANG modules.*

"

If the design team thinks that this is heading in the right direction, 
then I'll commit the changes and push them to the github repo.  Draft 
attached.

> nowhere, this is as good as copying text describing examples.
At the moment, I think that the concrete examples are helpful to less 
familiar readers to help them understand the types of issues that are 
being faced.

Thanks,
Rob

---

From: Benoit Claise <[email-masked]>
Date: Thu, 28 Jun 2018 16:03:31 +0200

Hi,

It's a fact that standardization is slow ... up to the point where the 
RFCs are not adopted.
However, it's a moot point. Some of us dealing with their "customers" 
have no time and willingness to try to convince the others.
Therefore, I like the move from "Slow Standardization" to "Striving for 
model perfection". Let's move on.

Btw, this draft is good enough IMO. Let's shoot it.
However, we can still try to improve it during this coming hour.

Regards, Benoit
> At the moment, I think that we just need to get an initial draft of 
> the requirements document out of the door before the end of the week.  
> As you say, it is not clear where this document will end up, and 
> spending lots of time on this now probably doesn't help.
>
> To that end:
>  3) I've changed the last sentence of the "non backwards compatible 
> bug fix" from "Still current YANG rules would force a module name 
> change." to "Current YANG rules are ambiguous as to whether non 
> backwards compatible bug fixes are allowed without also requiring a 
> module name change."
> some cases, YANG models are even derived from other data models that 
> do allow (controlled) non-backwards compatible changes." to "In some 
> cases, YANG models are mechanically derived from other data models 
> that do allow (controlled) non-backwards compatible changes."
>     agile development processes,*whilst retaining the ability for servers to support clients using 
> older versions of YANG modules.*
> "
>