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

[Jernej Tuljak <[e-mail]>]

On 13/05/2021 18:04, Ladislav Lhotka wrote:
>
> On 13. 05. 21 17:39, Sterne, Jason (Nokia - CA/Ottawa) wrote:
>> 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.
> 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/

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

>
> Lada
>
>> Jason
>>
>>> -----Original Message-----
>>> From: netconf <[e-mail]> On Behalf Of Jernej Tuljak
>>> Sent: Wednesday, May 12, 2021 7:44 AM
>>> To: Netconf <[e-mail]>
>>> Subject: Re: [netconf] YANG Library 1.1: a deviation module may exist
>>> without a module entry?
>>>
>>> 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:
>>>> 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
>>>>
>>>> _______________________________________________
>>>> netconf mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/netconf
>>> _______________________________________________
>>> netconf mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/netconf
>> _______________________________________________
>> netconf mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/netconf
>>