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

["Sterne, Jason (Nokia - CA/Ottawa)" <[e-mail]>]

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

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