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.
>
> > 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 <lho...@nic.cz> 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
> > > netmod@ietf.org
> > > https://www.ietf.org/mailman/listinfo/netmod
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
--
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
