Subject: [Netmod-ver-dt] PLEASE REVIEW: draft-verdt-netmod-yang-versioning-reqs-00

From: Joe Clarke <[email-masked]>
Date: Thu, 28 Jun 2018 10:43:02 -0400

Attached is the proposed final -00 version of the problem statement and
requirements.  This folds in Rob's latest changes to move existing
problem text to a background section, adds Jürgen's text as the main
problem statement, and fixes a few typos here and there.

We have a deadline to submit by this Monday (July 2).  Please review and
provide any last-minute comments.

Joe

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 29 Jun 2018 08:52:28 +0200

A few comments inline. I do not care that much but I thought I share
them anyway. Overall, I think the document is in a good shape for a
-00 version.

/js

On Thu, Jun 28, 2018 at 10:43:02AM -0400, Joe Clarke wrote:
> 
>    While Standards Development Organization (SDO) YANG modules are
>    obviously better for the industry, we must recognize that many YANG
>    modules are actually generated YANG modules (for example, from
>    internal databases), also known as native YANG modules, or vendor
>    modules [RFC8199].  From time to time, the new YANG modules are not
>    backward-compatible.

Can we remove ', also known as native YANG modules, or vendor modules
[RFC8199]'. Not all vendor modules are generated YANG modules nor do I
think calling generated YANG modules 'native YANG modules' is a good
idea. And these new terms do not seem to serve any purpose.

> 2.3.  Non-Backward Compatible Errors
> 
>    Sometimes small errors force us to make non-backward compatible
>    updates.  As an example imagine that we have a string with a complex
>    pattern (e.g., an IP address).  Let's assume the initial pattern
>    incorrectly allows IP addresses to start with 355.  In the next
>    version this is corrected to disallow addresses starting with 355.
>    Formally this is a non-backward compatible change as the value space
>    of the string is decreased.  In reality an IP address and the
>    implementation behind it was never capable of handling an address
>    starting with 355.  So practically this is a backward compatible
>    change, just like a correction of the description statement.  Current
>    YANG rules are ambiguous as to whether non-backwards compatible bug
>    fixes are allowed without also requiring a module name change.

This example is still confusing. If this is a backwards compatible
change (next to last sentence), then what does the example provide?

>    o  It is possible to change the semantic behavior of a data node,
>       action or rpc while the YANG definition does not change (with the
>       possible exception of the description statement).

Why? Only if you break the update rules?

>    o  Problems with the deprecated and obsolete status statement,
>       Section 2.7
> 
>    o  Modelers might decide to violate YANG 1.1 update rules for some of
>       the reasons above.
> 
>    Finding status changes or violations of update rules need a line-by-
>    line comparison of the old and new modules is a tedious task.

There are tools that do even better than line-by-line comparison by
comparing parse trees. Finding status changes is actually not a big
deal.  Finding violations of update rules can be automated partially
but not in an entirely automated process.

>    o  Tooling/SW is often not prepared to handle multiple revisions of
>       the same YANG module.

If this is true, then anything NETMOD will do will likely fail as
well. ;-)

/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: Benoit Claise <[email-masked]>
Date: Fri, 29 Jun 2018 09:42:58 +0200

> idea. And these new terms do not seem to serve any purpose.
Proposal: also known as native YANG modules (sometimes the case for 
vendor modules [RFC8199])

Regards, Benoit

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 29 Jun 2018 11:28:44 +0200

On Fri, Jun 29, 2018 at 09:42:58AM +0200, Benoit Claise wrote:
> Proposal: also known as native YANG modules (sometimes the case for vendor
> modules [RFC8199])

I would not call a generated YANG module a 'native' YANG module and I
do not think this term is needed (nor does it appear in RFC 8199).

If you want to preserve the reference to RFC 8199, you could do
'... generated YANG modules (sometimes the case for vendor modules
[RFC8199])'.

/js

---

From: Benoit Claise <[email-masked]>
Date: Fri, 29 Jun 2018 11:40:28 +0200

these new terms do not seem to serve any purpose.

> '... generated YANG modules (sometimes the case for vendor modules
That works.
Thanks, and enjoy your vacation.

Regards, Benoit

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Fri, 29 Jun 2018 15:25:25 +0000

Nits:
- I see use of both "backward" and "backwards", I believe the correct term is "backward".
- s/rpc/RPC/
- s/programing/programming/

Regards,
Reshad.

On 2018-06-28, 10:43 AM, "Netmod-ver-dt on behalf of Joe Clarke" <[email-masked] on behalf of jclarke=[email-masked]> wrote:

    
    Joe

---

From: Joe Clarke <[email-masked]>
Date: Fri, 29 Jun 2018 11:32:30 -0400

> - I see use of both "backward" and "backwards", I believe the correct term is "backward".

Fixed.

> - s/rpc/RPC/

In this context (action or rpc) it refers to a YANG type, so I think
lowercase is okay.

> - s/programing/programming/

Fixed.  I don't know why my typo check didn't find this one.

Thanks.

Joe

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

---

From: Joe Clarke <[email-masked]>
Date: Fri, 29 Jun 2018 11:39:54 -0400

> idea. And these new terms do not seem to serve any purpose.

I've corrected this based on subsequent comments.

> change (next to last sentence), then what does the example provide?

I agree.  I suggest that sentence is removed or changed to:

According to strict updating rules, this change is non-backward
compatible, but required to achieve desired functionality.

> Why? Only if you break the update rules?

Yes, the update rules do state that this type of change is not allowed.
I think perhaps the point trying to be made is that these changes are
done (or sometimes necessary).  Instead of "possible," should it read,
"sometimes necessary."

> but not in an entirely automated process.

But a detailed comparison is needed as today one does not have a hint
that backward incompatible changes may exist.  Maybe line-by-line should
simply read "detailed" or "deep".

> If this is true, then anything NETMOD will do will likely fail as

I don't think so.  If one of our goals is to ensure that clients can
maintain backward compatibility, then they can continue to function in
the case where multiple revisions/versions of a YANG module are
presented from a given server.

Joe

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 29 Jun 2018 22:40:20 +0200

> compatible, but required to achieve desired functionality.

As explained in earlier emails, I do not consider this bug fix to be a
non-backward compatible change. While the pattern allows 355, it is
clear that this won't be in the range of an IP address. I think the
example is simply a bad example - and I personally believe that bug
fixes are not necessarily falling under the RFC 7950 rules, in
particular in situations where the intent of the definition has been
clear.

> done (or sometimes necessary).  Instead of "possible," should it read,

I think "sometimes necessary" better conveys what you want to say.

> simply read "detailed" or "deep".

So we are talking about drawbacks of possible future update rules? I
did not get that - I thought this text talks about problems
experienced with the current update rules. But if you allow semantic
changes, then these won't be a violation of update rules. I am still
not clear what the sentence is trying to tell me. But yes, 'detailed'
clearly is better than 'line-by-line'. Perhaps you also mean 'detailed
manual' - but I am not sure since I am generally not sure what this
sentence is trying to tell.

> presented from a given server.

Again, I do not see the point made concerning today's update rules nor
do I see how things become better / easier if you allow semantic
changes.

/js

---

From: Joe Clarke <[email-masked]>
Date: Fri, 29 Jun 2018 17:09:30 -0400

> particular in situations where the intent of the definition has been

The point about the ambiguous nature of backward incompatible bug fixes
is valid.

Yes, the example is perhaps too weak.  Maybe something stronger is a set
of nodes that are used to define a tunnel endpoint.  The original
definition has "destination" as optional, but without it a tunnel cannot
be created (and thus the configuration is not valid).  A revision makes
"destination" mandatory.  This is backward incompatible, but a fix to
the bug.

> I think "sometimes necessary" better conveys what you want to say.

Changed.

> sentence is trying to tell.

In order for me to determine what has changed and whether or not it is
backward compatible _may_ involve a line-by-line comparison and human
reasoning (so I agree: manual) approach.  Yes, some things can be
determined with pure tooling.

I think this statement goes to the requirement that we should offer a
way to note specific node-level changes.

> do I see how things become better / easier if you allow semantic

The point I take from this background section is that semantic changes
are happening today.  If we provide a way to indicate them, it helps
operators better adapt to those changes.

Joe