On Tue, 2017-12-19 at 06:43 -0500, Lou Berger wrote:
> Hi Lada,
>
> On 12/19/2017 6:23 AM, Ladislav Lhotka wrote:
> > 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.
>
> Agreed - that's why I asked to start this thread!
>
> Here's the original proposal:
>
> How about at the end of the section [3.2] adding a new
> paragraph along the lines of:
>
> It is important to note that both YANG Library and Schema
> Mount Modules contain only operational state data. As such,
s/contain/define/
> the information in these modules should be retrieved by
> clients from operational data stores using the appropriate
This is based on two assumptions:
1. For every configuration datastore there is a corresponding operational
datastore.
2. For every mount point instance in any configuration datastore there is a
corresponding mount point instance (with the same path) in an operational
datastore.
I think that neither of these has to be true in general.
> protocol operations.
In contrast, the substance of my proposal with metadata annotations is to be
able to retrieve all schemas from a well-known location in *the* <operational>
datastore, namely from the top-level YANG library.
>
> Given this discussion, we can generalize it further to:
>
> The use of mount points does not impact the nature of the
> mounted data or in which data store information is made
> available. For example, mounted YANG Library modules contain
> only operational state data and, as such, the information in
> these modules is available from operational data stores using
> the appropriate protocol operations.
The whole question here is whether and how we can locate the schema for an
inline mount point in any configuration datastore.
Lada
>
> Lou
>
> > 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
