Re: [netmod] schema mount and YANG library

[Ladislav Lhotka <[e-mail]>]

On Tue, 2017-12-19 at 06:20 -0500, Lou Berger wrote:
> Lada,
> 
> 
> On December 19, 2017 1:12:35 AM Ladislav Lhotka <[e-mail]> wrote:
> 
> > On Mon, 2017-12-18 at 15:30 -0500, Lou Berger wrote:
> > > lada,
> > > 
> > >     See below.
> > > 
> > > 
> > > On 12/15/2017 8:59 AM, Ladislav Lhotka wrote:
> > > > Hi,
> > > > 
> > > > unfortunately, using an action for querying embedded YANG library data
> > > > (needed for the "inline" case of schema mount) doesn't work either
> > > > because now under NMDA actions can be used only on instances in the
> > > > <operational> datastore.
> > > 
> > > but the inline/embedded library would (only) be present in the in the
> > > operational datastore, so what's the issue?
> > 
> > Well, the issue is described in my initial mail of this thread: the current 
> > text
> > requires that every instance of an inline mount point contains the embedded 
> > YANG library. Tha latter is state data, so the above requirement cannot be 
> > satisfied if the mount point instance is in a configuration datastore.
> > 
> 
> That's not how I read the intent of the current text.  I don't see SM 
> impacting which data stores information is presented.  Just like use of 
> scheme mount doesn't transform RO configuration information into 
> operational information.  I sent you a couple of sentences clarifying this 
> at one point, I'll dig up the proposed text and resend.

Please do, this has to be discussed in the WG mailing list.

Lada

> 
> Lou
> > > 
> > > > However, a good alternative seems to be a metadata annotation along the
> > > > lines of RFC 7952, for example with the alternative B of the newly
> > > > proposed YANG library schema:
> > > > 
> > > >      md:annotation schema-ref {
> > > >        type leafref {
> > > >          path "/yanglib:yang-library/yanglib:schema/yanglib:name";
> > > >        }
> > > >      }
> > > > 
> > > > In other words, all inline mounted schemas would be included in the
> > > > top-level YANG library, and mount point instances in all datastores
> > > > would be annotated with leafref pointing to the actual schema.
> > > > 
> > > > Unlike regular state data, it is IMO no problem to permit such
> > > > annotations in configuration datastores.
> > > > 
> > > > Opinions?
> > > 
> > > I'm not sure this will work for all architectures of LNEs as well as
> > > other possible future use cases.  In short, this seems *very* restrictive.
> > 
> > I don't understand, IMO it is not restrictive at all. What kind of
> > restrictions
> > do you see?
> > 
> > Lada
> > 
> > > 
> > > Lou
> > > 
> > > > 
> > > > Thanks, Lada
> > > > 
> > > > Ladislav Lhotka <[e-mail]> writes:
> > > > 
> > > > > Hi,
> > > > > 
> > > > > the following text in sec. 3.2 of schema-mount-08 is wrong for
> > > > > traditional
> > > > > datastores, and even more so for NDMA:
> > > > > 
> > > > >    In case 1 ["inline"], the mounted schema is determined at run time:
> > > > > every
> > > > >    instance of the mount point that exists in the parent tree MUST
> > > > >    contain a copy of YANG library data [RFC7895] that defines the
> > > > >    mounted schema exactly as for a top-level data model.  A client is
> > > > >    expected to retrieve this data from the instance tree, possibly
> > > > > after
> > > > >    creating the mount point.  Instances of the same mount point MAY
> > > > > use
> > > > >    different mounted schemas.
> > > > > 
> > > > > An instance of the mount point in any *configuration* datastores
> > > > > cannot
> > > > > contain
> > > > > YANG library (being state data), and so the MUST cannot hold.
> > > > > 
> > > > > It is not clear to me how to repair this without considerable
> > > > > complications
> > > > > and/or a lot of handwaving. There is actually one good solution but it
> > > > > has
> > > > > impact on YANG library: the server could provide it in a reply to an
> > > > > operation,
> > > > > say "get-yang-library" rather than as state data. Then everything
> > > > > would be
> > > > > fine
> > > > > - this operation would turn into an action for the mount point, and it
> > > > > can
> > > > > be
> > > > > used equally well for config true and false mount points.
> > > > > 
> > > > > So my proposal is to move from YANG library as state data to an
> > > > > operation.
> > > > > It
> > > > > could be done along with changing the YANG library structure, so there
> > > > > will be
> > > > > little extra impact on implementations.
> > > > > 
> > > > > Lada
> > > > > 
> > > > > --
> > > > > Ladislav Lhotka
> > > > > Head, CZ.NIC Labs
> > > > > PGP Key ID: 0xB8F92B08A9F76C67
> > > > > 
> > > > > _______________________________________________
> > > > > netmod mailing list
> > > > > [e-mail]
> > > > > https://www.ietf.org/mailman/listinfo/netmod
> > > 
> > > _______________________________________________
> > > netmod mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/netmod
> > 
> > --
> > Ladislav Lhotka
> > Head, CZ.NIC Labs
> > PGP Key ID: 0xB8F92B08A9F76C67
> > 
> 
> 
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67