On Tue, 2017-12-19 at 06:20 -0500, Lou Berger wrote:
> Lada,
>
>
> On December 19, 2017 1:12:35 AM Ladislav Lhotka <[email protected]> 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 <[email protected]> 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
> > > > > [email protected]
> > > > > https://www.ietf.org/mailman/listinfo/netmod
> > >
> > > _______________________________________________
> > > netmod mailing list
> > > [email protected]
> > > 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
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
