Subject: [netconf] YANG Library 1.1: a deviation module may exist without a module entry?

From: Jernej Tuljak <[email-masked]>
Date: Wed, 12 May 2021 11:18:47 +0200

Hi,

is there a particular reason for the deviation leaf-list in 
ietf-yang-library@2019-01-04 not having require-instance true for its 
leafref path, therefore allowing servers to report "incomplete" module 
sets/schemas to the client?

      grouping module-implementation-parameters {
        description
          "Parameters for describing the implementation of a module.";
        leaf-list feature {
          type yang:yang-identifier;
          description
            "List of all YANG feature names from this module that are
             supported by the server, regardless whether they are defined
             in the module or any included submodule.";
        }
        leaf-list deviation {
          type leafref {
            path "../../module/name";
          }

          description
            "List of all YANG deviation modules used by this server to
             modify the conformance of the module associated with this
             entry.  Note that the same module can be used for deviations
             for multiple modules, so the same entry MAY appear within
             multiple 'module' entries.

             This reference MUST NOT (directly or indirectly)
             refer to the module being deviated.

             Robust clients may want to make sure that they handle a
             situation where a module deviates itself (directly or
             indirectly) gracefully.";
        }
      }

Why are deviation modules allowed to exist without a module entry within 
YANG Library instances? Why would a server choose to withhold namespace 
information for a deviation module?

Jernej

---

From: Jernej Tuljak <[email-masked]>
Date: Wed, 12 May 2021 13:43:52 +0200

Somehow it slipped my mind that require-instance defaults to true in 
YANG 1.1. Everything checks out.

A server implementation that announces a deviation module in the 
"/yang-library/module-set/module/deviation" leaf-list, but lacks a 
corresponding entry in "/yang-library/module-set/module" list is 
non-RFC8525 compliant.

Jernej

On 12/05/2021 11:18, Jernej Tuljak wrote:
> Why are deviation modules allowed to exist without a module entry 
> within YANG Library instances? Why would a server choose to withhold 
> namespace information for a deviation module?
>
> Jernej
>
> _______________________________________________
> netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

---

From: "Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked]>
Date: Thu, 13 May 2021 15:39:56 +0000

The concept of "deviation module" is a bit odd IMO in RFC8525.

Deviation statements can sit in any module and can be mixed in a module that declares other schema nodes (containers, lists, etc).

Maybe it is a nice idea for authors to gather deviations into modules that contain nothing but deviation statements, but that would just be a convention of how to organize your modules. Nothing in the specs really requires that.

Jason

> -----Original Message-----
> From: netconf <[email-masked]> On Behalf Of Jernej Tuljak
> Sent: Wednesday, May 12, 2021 7:44 AM
> To: Netconf <[email-masked]>
> Subject: Re: [netconf] YANG Library 1.1: a deviation module may exist
> without a module entry?
>

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 13 May 2021 18:04:26 +0200

> Maybe it is a nice idea for authors to gather deviations into modules that contain nothing but deviation statements, but that would just be a convention of how to organize your modules. Nothing in…

Right, I never really understood why the "deviation" leaf-list was
needed in the first place, given that it is completely redundant. It
just creates ambiguous situations:

https://mailarchive.ietf.org/arch/msg/netconf/BPVPQf-I9p-1C1K5NLmSsk0K_D8/

Lada

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

---

From: Andy Bierman <[email-masked]>
Date: Thu, 13 May 2021 10:38:21 -0700

On Thu, May 13, 2021 at 9:04 AM Ladislav Lhotka <[email-masked]>
wrote:

> > Deviation statements can sit in any module and can be mixed in a module
> that declares other schema nodes (containers, lists, etc).
> >
> > Maybe it is a nice idea for authors to gather deviations into modules
> that contain nothing but deviation statements, but that would just be a
> convention of how to organize your modules. Nothing in the specs really
> requires that.
>
+1 (!)

The deviation list helps compilers know where to find the deviations for
the target module being compiled.
But they cannot really rely on it for many reasons.

I tried to get the WG to use a separate deviations module instead of
allowing
deviations for anything to be mixed in any regular module.
(But YANG is supposed to be easy for readers, almost easy for writers,
and almost impossible for tool makers ;-)

In reality vendors are struggling with the complex mix of overlapping
standards,
proprietary extensions, platform and version specific deviations, and
implementation-specific annotations.
But at least they do not mix deviations and regular statements in the same
module.

(One thing I never hear from customers:
"Please make YANG even more complicated.  We love a good challenge.")

Lada
Andy

---

From: Jernej Tuljak <[email-masked]>
Date: Fri, 14 May 2021 09:07:38 +0200

> https://mailarchive.ietf.org/arch/msg/netconf/BPVPQf-I9p-1C1K5NLmSsk0K_D8/

Perhaps this was an attempt to ensure the order of applying deviation 
modules to the target module, which may be relevant in some cases (that 
are bad practice and should be avoided anyway).

We encountered a couple of implementations that do the opposite of what 
you (Ladislav) pointed out in that archive thread - they only list 
deviation modules in the "leaf-list"...

Another potential caveat: because of the way the "path" expression for 
this "leafref" is defined ("../../module/name" as opposed to 
"../../../module-set/module/name"), you cannot put a module that 
contains deviations in one module-set as an implementation module and 
reference it in another module-set via this "leaf-list's" value.

   <yang-library xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-library">
     <module-set>
       <name>deviations</name>
       <module>
         <name>foo-devs</name>
         <namespace>urn:foo:devs</namespace>
       </module>
     </module-set>
     <module-set>
       <name>common</name>
       <module>
         <name>foo</name>
         <namespace>urn:foo</namespace>
         <deviation>foo-devs</deviation>
       </module>
     </module-set>
     // ...
   </yang-library>

The above instance is not valid according to the model, which I think is 
fine, but may be confusing for some, especially if you consider 
"referential completeness"  of "imports", which only need to become 
complete once woven into a schema list entry, as stated in several 
"description" texts.

Jernej

---

From: "Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked]>
Date: Thu, 27 May 2021 15:00:00 +0000

Hi Jernej,

You may have identified a problem with Library 1.1 but I'm not certain. Does anybody know if it was intended to prevent deviations from being in a different module-set than the modules being deviated ?  I'm doubtful that was the intention (given the text you mention below where a module-set is allowed to be referentially incomplete on its own).

Jason

> Sent: Friday, May 14, 2021 3:08 AM
> To: Ladislav Lhotka <[email-masked]>; [email-masked]
> >> Maybe it is a nice idea for authors to gather deviations into modules that
> contain nothing but deviation statements, but that would just be a