Subject: [Netconf] rfc7895bis - deviation modules in YANG library

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 13 Feb 2018 07:29:23 +0100

Hi,

why is it necessary to list deviation modules with the recipient modules (in the
"deviation" list), and then again in the "module" list of the module set?

What happens if a deviation module is listed in the latter place but not in the
former? Does it apply? This situation doesn't seem to be addressed in the
document.

In my opinion, it should suffice to include deviation modules only in the
"module" list, as other modules.

Lada

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 13 Feb 2018 10:59:25 +0100

I think this is inherited from RFC 7895, which had a deviation list.
The term 'deviation module' is actually not well defined. There seems
to be a certain assumption here how deviation definitions are
organized that is not spelled out. YANG (RFC 7950) does not seem to
require any specific organization, i.e., deviation statements can
pretty much appear in any module. (It likely makes sense to separate
deviation definitions into separate modules but this does not seem to
be required.)

So yes, I tend to agree that it is not clear why we actually have this
separate deviation list. Perhaps there is a reason which is just not
well documented anywhere - I can't tell. Perhaps the authors of
RFC 7895 can explain this.

/js

On Tue, Feb 13, 2018 at 07:29:23AM +0100, Ladislav Lhotka wrote:
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

-- 
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: Ladislav Lhotka <[email-masked]>
Date: Tue, 13 Feb 2018 12:44:05 +0100

> I think this is inherited from RFC 7895, which had a deviation list.

In fact it comes from RFC 6020, the hello capabilities have the same issue.

> deviation definitions into separate modules but this does not seem to

Right, and augments are very similar in this respect. All modules have to be
parsed in order to construct the schema.

This actually leads to another question: the leafref definition for
deviation/module restricts deviation targets to the same module set. But what
happens if a deviation is specified across module sets?

And what about augments? Is it possible to define an augment with the target
node being in a different module set?

In my view, modules comprising a schema should be taken from all modules sets of
the schema, and both augments and deviations applied irrespectively of module
sets.

> RFC 7895 can explain this.

Yes, otherwise the deviation list should be removed from /yang-library (and left
in /modules-state).

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 13 Feb 2018 12:44:52 +0100 (CET)

Hi,

The same concept was actually present already in RFC 6020, where the
capability string for a module contains information about which module
it is (name and revision), which features are supported, and if it is
deviated.  This means that the client has the information "up front";
if a server claims that it implements

  http://example.com/syslog?module=syslog&amp;revision=2008-04-01

the client knows exactly what is implemented, without having to first
download all other modules, then scan and parse them.

This is still true in YANG Library, but in a slightly different form
(oper data instead of special protocol message).

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 13 Feb 2018 13:19:31 +0100

> download all other modules, then scan and parse them.

Realistically, I think the client needs to have the other modules anyway in
order to apply potential augments and collect all identities.

> (oper data instead of special protocol message).

In any case, it is unclear what happens if a module containing deviations
appears in the "module" list but not in the "deviation" list.

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 13 Feb 2018 13:38:17 +0100 (CET)

> order to apply potential augments and collect all identities.

We've talked about this before, and I disagree.  All use cases do not
require the full set of all modules.

> appears in the "module" list but not in the "deviation" list.

That would be a reporting error in the server.  Compare what happens
if a server claims that it implements ietf-ip, but not
ietf-interfaces.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 13 Feb 2018 14:06:58 +0100

OK. So it is about communicating "this device is implementing module
foo and the deviations affecting foo are in dev1 and dev2". So the
benefit is that a client that only cares about foo and ignore the
rest. I think the objectives section does not describe this well. It
only says:

   o  deviation list: The name of each YANG module used for deviation
      statements, in a given datastore schema, MUST be identified.

I think this is more this:

   o  deviation list: The name of each YANG module used to deviation
      a given module, in a given datastore schema, MUST be identified.

Similarly, feature list probably needs to be better defined:

   o  feature list: The name of each YANG feature supported by the
      server for a given module, in a given datastore schema, MUST
      be identified.

And submodule list:

   o  submodule list: The name, and if defined, revision of each
      submodule used by a module MUST be identified.

Perhaps also add a numbered item that it should be possible to find
efficiently all modules defining deviations for a given module.

Perhaps wording in the YANG definitions likely needs improvement as
well:

      list deviation {
        key "module";
	description
          "List of YANG deviation modules used by this server to modify
           the conformance of the module associated with this entry.

It is somewhat unclear what 'this entry' means.

	   Note that the same module can be used for deviations for
           multiple modules, so the same entry MAY appear within
           multiple 'module' entries.";

What are multiple module entries? Rather unclear.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 13 Feb 2018 14:23:16 +0100

> if a server claims that it implements ietf-ip, but not

This is something else, I am not talking about the case when the module
containing the deviation target is not implemented. Both modules (with the
deviation and its target) are implemented, only the former isn't contained in
the "deviation" list of the latter. The description of the "module" list also
says:

           The server implements one or more protocol-accessible
           objects defined in the YANG module identified in this entry.
           This includes deviation statements defined in the module.";

This seems to imply that the deviation statements are implemented
unconditionally.

Lada

> > > > > why is it necessary to list deviation modules with the recipient
> modules
> > > (in the
> > > > > What happens if a deviation module is listed in the latter place but
> not
> > > in the

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 13 Feb 2018 14:26:06 +0100 (CET)

Ladislav Lhotka <[email-masked]> wrote:
> the "deviation" list of the latter.

This is still an error.

> The description of the "module" list also
> says:
> 

Yes.  See also RFC 7950:

5.6.5.  Implementing a Module

   A server implements a module if it implements the module's data
   nodes, RPCs, actions, notifications, and deviations.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 13 Feb 2018 15:47:22 +0100

> > the "deviation" list of the latter.

Not sure why.

>    nodes, RPCs, actions, notifications, and deviations.

I don't know what to take from the above.

Are you saying that the deviation is implemented/applied if the module where it
is defined appears in the list of implemented modules, even if it is NOT present
in the "deviation" list of the module in which the deviation's target node is
defined?

Lada

> > > > > > > "deviation" list), and then again in the "module" list of the
> module
> > > set?
> > > > > > > 
> > > > > > > former? Does it apply? This situation doesn't seem to be addressed
> in
> > > the
> > > > > > > document.
> > > > > > > 
> > > > > > > In my opinion, it should suffice to include deviation modules only
> in
> > > the

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 13 Feb 2018 16:02:10 +0100 (CET)

> > > the "deviation" list of the latter.

Listing the module with the deviation statements in the "module" list
is a requirement.

Then, having a "pointer" to the deviation module from the deviated
module is a "nice to have" (but a strong one, so it is a MUST).

> Are you saying that the deviation is implemented/applied if the
> module where it is defined appears in the list of implemented
> modules, even if it is NOT present in the "deviation" list of the
> module in which the deviation's target node is defined?

I am saying that this would be an error.  The server MUST provide both
pieces of information.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 13 Feb 2018 18:50:27 +0100

On Tue, 2018-02-13 at 16:02 +0100, Martin Bjorklund wrote:
> > > > > > Realistically, I think the client needs to have the other modules
> anyway
> > > in
> > > > deviation and its target) are implemented, only the former isn't
> contained
> > > in

It is certainly redundant information and the descriptions can indeed be
interpreted as "nice to have", so it's quite a stretch to say that it is a MUST.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Tue, 13 Feb 2018 10:04:33 -0800

On Tue, Feb 13, 2018 at 9:50 AM, Ladislav Lhotka <[email-masked]> wrote:

> > > > > > > > The same concept was actually present already in RFC 6020,
> where
> > the
> > > > > > > > capability string for a module contains information about
> which
> > module
> > > > > > > > it is (name and revision), which features are supported, and
> if it
> > is
> > > > > > > > the client knows exactly what is implemented, without having
> to
> > first
> > > > > > > > This is still true in YANG Library, but in a slightly
> different
> > form
> > > > > containing the deviation target is not implemented. Both modules
> (with
> > the

I am strongly opposed to changing the contents of the module list.
Applications already exist that use this data.
Unless it is broken somehow, then don't change it.
This module entry is the YANG version of the module capability URI.
It MUST contain all the info that was in that URI.

> Lada

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 14 Feb 2018 12:50:06 +0100

> It MUST contain all the info that was in that URI.

I don't propose to change it, just clarify. It is important because it
is a part of data model definition, and ambiguous interpretations can
lead to interoperability problems.

My suggestion is to change the description of the "module" list like so:

OLD

NEW
           The server implements one or more protocol-accessible
           objects defined in the YANG module identified in this entry.
           Deviation statements defined in the module are applied if and
           only if the module appears in the 'deviation' list of the
           deviated module.";

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 14 Feb 2018 13:14:56 +0100

>            only if the module appears in the 'deviation' list of the

This sounds broken to me. A deviation defined in a module that is
'implemented' suddenly becomes conditional? Please no. My
understanding is that case you are trying to cover is an error in the
server's YANG Library information.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 14 Feb 2018 13:32:37 +0100

> server's YANG Library information.

If it is an error, the text should say so - it doesn't. I started this thread
with the view that it is enough to have such a module implemented, and the
"deviation" list is only nice to have.

BTW, what is the reason to have "deviation" as a list with the key "module"
being its only child? This just adds one level of hierarchy, a leaf-list would
seem to suffice. Could there be any need to e.g. augment this list? I don't
think so.

Lada