Subject: Re: [netmod] schema mount and YANG library

From: Lou Berger <[email-masked]>
Date: Mon, 15 Jan 2018 16:20:21 -0500

Lada/Martin,

I don't believe we reached closure on this discussion.  The open issues 
relate to proposed new text (slightly modified):

at the end of the section [3.2] adding a new paragraph along the
lines of:

   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 define
   only operational state data and, as such, the information in
   these modules is available from operational data stores using
   the appropriate protocol operations.  It is also worth
   noting that the Schema Mount module itself parallels the
   YANG Library module and only defines operational state data.

Is this change acceptable?

What other issues related to SM are outstanding?

Thank you,

Lou

On 12/19/2017 8:26 AM, Ladislav Lhotka wrote:
> On Tue, 2017-12-19 at 07:49 -0500, Lou Berger wrote:
>> On 12/19/2017 7:36 AM, Ladislav Lhotka wrote:
>>> 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-masked]> 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.
>> well the text is revised below.  In any case, "these modules" refers to
>> yang library, and yes, I'm assuming YL is always and only in
>> operational.  If the revised text below isn't clear s/these/YANG Library/ -
> The thing is that we have the top-level YANG library in <operational>, and then
> embedded YANG libraries scattered inside inline mount point instances.
>
>>> 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.
>> agreed in general, but for inline, where YL is required, it must be true.
> How do you know? I provided an example in Singapore where a mount point instance
> in <intended> is a part of pre-provisioned data (for non-existent hardware).
> Then, according to the NMDA rules there is no corresponding instance in
> <operational>, hence no place where the embedded YANG library can be placed.
> (I can easily provide a concrete example if needed).
>
>
> Dean replied that this cannot happen, so it seems there are some assumptions how
> the inline method of schema mount may be applied. If so, these assumptions have
> to be explicitly stated.
>
>>>>    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.
>> What about a schema that is based on dll that contains modules that
>> isn't loaded until a mount point is instantiated -- this is certainly a
>> valid approach for supporting LNEs, but would be precluded in this
>> approach.  I really don't think a top level approach works for all
>> inline (managed) types of mounts.
> It isn't precluded: when the mount point is instantiated (no matter which
> datastore it is in), the server adds the schema as a new entry to the "schema"
> list in the top level YANG library (with a unique key), and annotates the mount
> point instance with a leafref pointing to that key. So different instances of
> the same mount point can have different schemas.
>
>>>> 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.
>> Why is a mounted YL different than a top level YL?  What works for and
> It is not different, but it can be only in an operational datastores, and so for
> mount point instances inside configuration datastores we need a way how to
> locate the schema for that mount point, because it cannot be found directly
> under the mount point instance (as the current text assumes).
>
>> is sufficient for the normal case of YL shouldn't be impacted or
>> modified by SM -- at least that's how I thought we've been talking about
>> since SM was started.  Again, we never made any special provisions for
>> any other rw/ro/state data, assuming top level YL is not handled as
>> metadata, why start now?
>>
>> I'm getting the impression that your argument may be more about if YL
>> should be treated as something other than operational data, is this wrong?
> This is wrong. My argument is that there should be only one top-level YANG
> library (state data) and each inline mount point instance just points to a
> schema inside it by means of a metadata annotation attached to the mount point
> (in any datastore).
>
> Lada
>
>> Thanks,
>> Lou
>>
>>> 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-masked]> 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-masked]
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>>>>>> _______________________________________________
>>>>>>>> netmod mailing list
>>>>>>>> [email-masked]
>>>>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>>>>> --
>>>>>>> Ladislav Lhotka
>>>>>>> Head, CZ.NIC Labs
>>>>>>> PGP Key ID: 0xB8F92B08A9F76C67
>>>>>>>
>>

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 16 Jan 2018 08:14:07 +0100

Hi Lou,

in my view, we should do the following two (significant) changes:

1. Instead of borrowing a grouping from ietf-yang-library and having a parallel
list of mounted schemas, we should keep *all* mounted schemas directly in the
YANG library and refer to them from schema-mounts structures. Juergen suggested
this change and it is IMO the right thing to do.

2. Define a metadata annotation (e.g. @schema-ref) that would be required for
inline mount point instances and specify the inline-mounted schema also by
referring to a schema specified in YANG library.

The advantage of #2 is that an annotation can be attached equally well to both
state an configuration data. So, instead of papering over the issue that YANG
library (state data) cannot appear in configuration datastores, we can use this
general and straightforward approach. This also allows for defining different
mounted schemas for instances of the same mount point in different datastores.

I strongly believe that these changes (along with the new YANG library schema
and NMDA) make for a simple and elegant datastore architecture in which schema
mount would be an optional feature.

Lada

---

From: Lou Berger <[email-masked]>
Date: Tue, 16 Jan 2018 06:30:06 -0500

Lada,

It sounds like you are proposing in (1) a fairly significant change in the 
direction of the draft and in (2) a basic approach that has been 
rejectected by the WG multiple times.  FWIW there are drafts already with 
the iesg that will need to be returned to their WGs if either change is made.

Martin,

Do share Lada's view?

Lou

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 16 Jan 2018 13:06:44 +0100

> direction of the draft and in (2) a basic approach that has been

It is no change in direction, just a simplification of the schema-describing
state data. Given the recent developments in 7895bis it makes no sense to me to
have two "schema" lists if we can have just one.

> rejectected by the WG multiple times.  FWIW there are drafts already with

No at all. The first and last time I proposed this was on 15 December 2017:

https://www.ietf.org/mail-archive/web/netmod/current/msg19753.html

The only reply was from you. To me, it is the cleanest solution of the inline
case. Of course, I am open to technical objections.

If it's not clear what I mean, I can make up some examples.

Lada

> > > > > > > > > On December 19, 2017 1:12:35 AM Ladislav Lhotka <[email-masked]
> > > > > > > > > >
> > > > > > > > > wrote:
> > > > > > > > > 
> > > > > > > > > > > > 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
> > > > > > > > > > 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
> > > > > > > > > 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
> > > > > operational.  If the revised text below isn't clear s/these/YANG
> > > > > Library/
> > > > > -
> > > > 
> > > > The thing is that we have the top-level YANG library in <operational>,
> > > > and
> > > > then
> > > > > > 2. For every mount point instance in any configuration datastore
> > > > > > there
> > > > > > is a
> > > > Dean replied that this cannot happen, so it seems there are some
> > > > assumptions
> > > > how
> > > > the inline method of schema mount may be applied. If so, these
> > > > assumptions
> > > > have
> > > > to be explicitly stated.
> > > > 
> > > > > > >    protocol operations.
> > > > > > 
> > > > > > In contrast, the substance of my proposal with metadata annotations
> > > > > > is
> > > > > > to be
> > > > list in the top level YANG library (with a unique key), and annotates
> > > > the
> > > > mount
> > > > point instance with a leafref pointing to that key. So different
> > > > instances
> > > > of
> > > > > > The whole question here is whether and how we can locate the schema
> > > > > > for
> > > > > > an
> > > > It is not different, but it can be only in an operational datastores,
> > > > and so
> > > > for
> > > > > > > > > > > > In other words, all inline mounted schemas would be
> > > > > > > > > > > > included
> > > > > > > > > > > > in
> > > > > > > > > > > > the
> > > > > > > > > > > > Unlike regular state data, it is IMO no problem to
> > > > > > > > > > > > permit
> > > > > > > > > > > > such
> > > > > > > > > > > I'm not sure this will work for all architectures of LNEs
> > > > > > > > > > > as
> > > > > > > > > > > well
> > > > > > > > > > > as
> > > > > > > > > > I don't understand, IMO it is not restrictive at all. What
> > > > > > > > > > kind
> > > > > > > > > > of
> > > > > > > > > > restrictions
> > > > > > > > > > do you see?
> > > > > > > > > > 
> > > > > > > > > > Lada
> > > > > > > > > > 
> > > > > > > > > > > Lou
> > > > > > > > > > > 
> > > > > > > > > > > > Thanks, Lada
> > > > > > > > > > > > 
> > > > > > > > > > > > > the following text in sec. 3.2 of schema-mount-08 is
> > > > > > > > > > > > > wrong
> > > > > > > > > > > > > for
> > > > > > > > > > > > > traditional
> > > > > > > > > > > > >     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
> > > > > > > > > > > > > YANG library (being state data), and so the MUST
> > > > > > > > > > > > > cannot
> > > > > > > > > > > > > hold.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > impact on YANG library: the server could provide it in
> > > > > > > > > > > > > a
> > > > > > > > > > > > > reply
> > > > > > > > > > > > > to
> > > > > > > > > > > > > an
> > > > > > > > > > > > > operation,
> > > > > > > > > > > > > So my proposal is to move from YANG library as state
> > > > > > > > > > > > > data
> > > > > > > > > > > > > to
> > > > > > > > > > > > > an
> > > > > > > > > > > > > operation.
> > > > > > > > > > > > > It

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 16 Jan 2018 13:19:09 +0100 (CET)

Ladislav Lhotka <[email-masked]> wrote:
> 1. Instead of borrowing a grouping from ietf-yang-library and having
> a parallel list of mounted schemas, we should keep *all* mounted
> schemas directly in the YANG library and refer to them from
> schema-mounts structures. Juergen suggested this change and it is
> IMO the right thing to do.

I agree.

> The advantage of #2 is that an annotation can be attached equally
> well to both state an configuration data. So, instead of papering
> over the issue that YANG library (state data) cannot appear in
> configuration datastores, we can use this general and
> straightforward approach. This also allows for defining different

This is a clever idea!  I assume this would be used instead of
requiring the mounting of ietf-yang-library and ietf-schema-mount?

For "peer mount", it might be the case that this doesn't work as well
as the current solution for inline, but I think it is ok.

> mount would be an optional feature.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 16 Jan 2018 13:25:18 +0100 (CET)

> have two "schema" lists if we can have just one.

I agree.  I have always thought that we would align schema mount to
7895bis.  Using an old version of yang library does not seem very
future proof.

/martin

---

From: Lou Berger <[email-masked]>
Date: Tue, 16 Jan 2018 07:26:26 -0500

Lada,

> have two "schema" lists if we can have just one.

Managing transition is hard. It's also highlights why Yang Library this 
needs to be at least equally discussed in this group.

I will talk with my co-chairs and perhaps the ADs to get their opinion on 
making such a change this point in the process.

> https://www.ietf.org/mail-archive/web/netmod/current/msg19753.html

Oh, I certainly would call you proposing that the schema for inline be part 
of the rest of the schema Mount module well before that. I'm sure I can dig 
up mail / slides it really necessary...

> case. Of course, I am open to technical objections.

I'm sure I can find material on this as well....

Lou

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 16 Jan 2018 13:29:30 +0100

> requiring the mounting of ietf-yang-library and ietf-schema-mount?

Right. It doesn't preclude mounting them though, e.g. for split management, but
then we can deal with it exactly as with NACM data: the embedded ietf-yang-
library and/or ietf-schema-mount will be ignored in the parent schema.

> as the current solution for inline, but I think it is ok.

I am not sure what you exactly mean but the data can be mounted dynamically as
before: the mount point instance is created, its schema written as a new entry
in the top-level YANG library, and the metadata annotation created pointing to
that schema.

Lada

---

From: Robert Wilton <[email-masked]>
Date: Tue, 16 Jan 2018 12:41:17 +0000

> this change and it is IMO the right thing to do.
I also support this approach.  I think that it easier for everyone if 
schema are defined in one place.

This was also the suggested approach that I presented at IETF 100 for 
the YANG library bis draft, which seemed to have reasonable support in 
the room, and I don't recall anyone objecting to this approach.

I also provided the same comment in November during the WG LC on schema 
mount ...

Thanks,
Rob

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 16 Jan 2018 14:24:07 +0100 (CET)

Lou Berger <[email-masked]> wrote:
> Managing transition is hard. It's also highlights why Yang Library
> this needs to be at least equally discussed in this group.
> 
> I will talk with my co-chairs and perhaps the ADs to get their opinion
> on making such a change this point in the process.
> 
> 
> >>
> Oh, I certainly would call you proposing that the schema for inline be
> part of the rest of the schema Mount module well before that. I'm sure
> I can dig up mail / slides it really necessary...

I don't think this has been proposed before.  All previous proposals
were basically variants on what is now "use-schema", which works fine
when all instances have the same schema.  This new proposal solves the
issue with different schemas in different instances.

> I'm sure I can find material on this as well....

Ok.

/martin

> >> > list of mounted schemas, we should keep *all* mounted schemas directly
> >> > in
> >> > the
> >> > 2. Define a metadata annotation (e.g. @schema-ref) that would be
> >> > required
> >> > for
> >> > The advantage of #2 is that an annotation can be attached equally well
> >> > to
> >> > both
> >> > state an configuration data. So, instead of papering over the issue
> >> > that
> >> > YANG
> >> > library (state data) cannot appear in configuration datastores, we can
> >> > use
> >> > this
> >> > and NMDA) make for a simple and elegant datastore architecture in
> >> > which
> >> > schema
> >> > > > > > > > > > > > (needed for the "inline" case of schema mount)
> >> > > > > > > > > > > > doesn't
> >> > > > > > > > > > > > work
> >> > > > > > > > > > > > either
> >> > > > > well the text is revised below.  In any case, "these modules"
> >> > > > > refers
> >> > > > > to
> >> > > > How do you know? I provided an example in Singapore where a mount
> >> > > > point
> >> > > > instance
> >> > > > > isn't loaded until a mount point is instantiated -- this is
> >> > > > > certainly
> >> > > > > a
> >> > > > mount point instances inside configuration datastores we need a way
> >> > > > how
> >> > > > to
> >> > > > library (state data) and each inline mount point instance just points
> >> > > > to
> >> > > > a
> >> > > > schema inside it by means of a metadata annotation attached to the
> >> > > > mount
> >> > > > point
> >> > > > (in any datastore).
> >> > > >
> >> > > > Lada
> >> > > >
> >> > > > > Thanks,
> >> > > > > Lou
> >> > > > >
> >> > > > > > Lada
> >> > > > > >
> >> > > > > > > Lou
> >> > > > > > >
> >> > > > > > > > Lada
> >> > > > > > > >
> >> > > > > > > > > Lou
> >> > > > > > > > > > > > lines of RFC 7952, for example with the alternative B
> >> > > > > > > > > > > > of
> >> > > > > > > > > > > > the
> >> > > > > > > > > > > > newly
> >> > > > > > > > > > > > would be annotated with leafref pointing to the
> >> > > > > > > > > > > > actual
> >> > > > > > > > > > > > schema.
> >> > > > > > > > > > > >
> >> > > > > > > > > > > > >     contain a copy of YANG library data [RFC7895]
> >> > > > > > > > > > > > >     that
> >> > > > > > > > > > > > > defines
> >> > > > > > > > > > > > > the
> >> > > > > > > > > > > > >     expected to retrieve this data from the
> >> > > > > > > > > > > > >     instance
> >> > > > > > > > > > > > > tree,
> >> > > > > > > > > > > > > possibly
> >> > > > > > > > > > > > > after
> >> > > > > > > > > > > > >     creating the mount point.  Instances of the
> >> > > > > > > > > > > > >     same
> >> > > > > > > > > > > > > mount
> >> > > > > > > > > > > > > point
> >> > > > > > > > > > > > > MAY
> >> > > > > > > > > > > > > use

---

From: Lou Berger <[email-masked]>
Date: Tue, 16 Jan 2018 08:29:21 -0500

> issue with different schemas in different instances.

I thought the previous proposals that as well, so don't see material 
difference - at least from the usage standpoint. I also don't see why the 
previous arguments that resulted in consensus for using Yang Library 
underneath the an in line Mount Point don't apply.

Lou

---

From: Robert Wilton <[email-masked]>
Date: Tue, 16 Jan 2018 13:40:46 +0000

On 16/01/2018 13:23, Lou Berger wrote:
> On 1/16/2018 7:41 AM, Robert Wilton wrote:
>>
>>> a parallel
> I think we have a question of what is workable vs what is optimal, 
> i.e., this proposal is arguably better for those supporting YL bis, 
> but the other isn't broken.   -- I have also raised this privately 
> with the chairs and ADs of the impacted groups (keep in mind that 
> RTGWG and BESS are already using the current definitions) to see if 
> they have opinions.
The NMDA solution to this problem is to publish both ...

E.g. either (i) publish SM now (so that folks can use) it but then 
immediately bis the draft, to cover YL-bis (probably keeping the 
existing library in the appendix).

Or (ii) put the current SM YANG library into the appendix (marked as 
deprecated) and include a new YL-bis compatible version in the body of 
the document.

> In the email discussion on the results of the December NetConf 
> interim, the sentiment was that YL bis shouldn't consider schema 
> mount.  As stated on the list, I personally (with all hats) think this 
> is a mistake and would likely feel differently if YL bis 
> covered/obsoleted schema mount.
I think that the conclusion was more nuanced that that:

YL-bis should not cover SM directly.  I.e. YL-bis should not contain SM 
specific nodes (even under a feature keyword).

However, there seems to good support for YL-bis being designed in an SM 
sympathetic way, such that SM can cleanly augment YL-bis and provide the 
required functionality without needing to a separate schema mount 
specific YANG library tree.

Thanks,
Rob

>>> required for
>>> well to both
>>> that YANG
>>> which schema
>>>>>>>>>> That's not how I read the intent of the current text.  I 
>>>>>>>>>> don't see
>>>>>>>>>> SM
>>>>>> refers to
>>>>> The thing is that we have the top-level YANG library in 
>>>>> <operational>, and
>>>>> then
>>>>>>> In contrast, the substance of my proposal with metadata 
>>>>>>> annotations is
>>>>>>> to be
>>>>>> certainly a
>>>>> list in the top level YANG library (with a unique key), and 
>>>>> annotates the
>>>>> mount
>>>>>>> The whole question here is whether and how we can locate the 
>>>>>>> schema for
>>>>>>> an
>>>>> It is not different, but it can be only in an operational 
>>>>> datastores, and so
>>>>> for
> .

---

From: Lou Berger <[email-masked]>
Date: Tue, 16 Jan 2018 08:23:28 -0500

> schema are defined in one place.

I think we have a question of what is workable vs what is optimal, i.e., 
this proposal is arguably better for those supporting YL bis, but the 
other isn't broken.   -- I have also raised this privately with the 
chairs and ADs of the impacted groups (keep in mind that RTGWG and BESS 
are already using the current definitions) to see if they have opinions.

> the room, and I don't recall anyone objecting to this approach.

In the email discussion on the results of the December NetConf interim, 
the sentiment was that YL bis shouldn't consider schema mount.  As 
stated on the list, I personally (with all hats) think this is a mistake 
and would likely feel differently if YL bis covered/obsoleted schema mount.

Lou

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 16 Jan 2018 14:50:03 +0100 (CET)

Lou Berger <[email-masked]> wrote:
> difference - at least from the usage standpoint. I also don't see why
> the previous arguments that resulted in consensus for using Yang
> Library underneath the an in line Mount Point don't apply.

B/c it doesn't work well with the NMDA.  You can't mount yang library
in the configuration datastores; it has to be mounted in operational.
With meta-data, you can actually report the correct schema even in
running.  (This is actually true also for pre-NMDA systems).

/martin

---

From: Lou Berger <[email-masked]>
Date: Tue, 16 Jan 2018 09:19:00 -0500

On 1/16/2018 8:40 AM, Robert Wilton wrote:
> E.g. either (i) publish SM now (so that folks can use)
This would permit the current dependent work to continue, uninterrupted 
so I think has a lot of benefit.
> it but then
Lots of variations on how to immediately address YL-bis and SM.  -- I 
think you know my preferred solution, but other are certainly workable.

> specific YANG library tree.

I'm certainly glad to hear that the topic of schema mount and server 
metadata will be / is being considered as part of YL-bis.  This is more 
than I thought was evidenced by the on-list discussion in December.

Lou

---

From: Lou Berger <[email-masked]>
Date: Tue, 16 Jan 2018 09:24:35 -0500

> running.  (This is actually true also for pre-NMDA systems).
Understood and agree there is nothing new here and the current version 
of SM (including inline) has the same limitation as rfc7895, and I'd 
expect it to behave the same once we have rfc7985bis -- in fact the 
inline case "just works" with YL-bis as defined today.

The argument I recall being the key point on inline was handling the 
large variety of possible different implementation approaches for 
modules using inline.  For example an LNE that is implemented using VMs 
which can be managed by the host at different times of the VMs 
operational life cycle based on customer/provider requirements.  I 
really don't see how YL-bis has any bearing on this point and I think it 
is incumbent upon those revisiting past/closed WG decisions (in this 
case, inline schema being represented by YL) to argue why the decision 
needs to be revisited.

Lou

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 16 Jan 2018 15:57:44 +0100

> E.g. either (i) publish SM now (so that folks can use) it but then

If folks means module authors, then they are IMO largely unaffected. As before,
they just have to place the mount-point extension to desired places in their
modules. Everything we discuss here is of interest to data model implementors.

> specific nodes (even under a feature keyword).

Absolutely. YL should be completely independent of schema mount.

> specific YANG library tree.

I think that schema-mount needn't even augment YL. Specifically, ietf-schema-
mount would do:

1. Define the "schema-mounts" hierarchy, the only change being that the "name"
leafref in the "use-schema" list now points to YL "schema" list entries rather
than to /schema-mounts/schema.

2. Extension "mount-point", exactly as before.

3. Metadata annotation "@schema-ref" for use with inline mount point instances.

All in all, a piece of cake.

Lada  

> > > > > > > > > > > On December 19, 2017 1:12:35 AM Ladislav Lhotka <lhotka@ni
> > > > > > > > > > > c.cz>
> > > > > > > > > > > wrote:
> > > > > > > > > > > 
> > > > > > > > > > > > > > doesn't work
> > > > > > > > > > > > > but the inline/embedded library would (only) be
> > > > > > > > > > > > > present in the
> > > > > > > > > > > > > in
> > > > > > > > > > > > > the
> > > > > > > > > > > impacting which data stores information is presented. 
> > > > > > > > > > > Just like
> > > > > > > > > > > use
> > > > > > > > > > > of
> > > > > > datastore it is in), the server adds the schema as a new entry to
> > > > > > the
> > > > > > "schema"
> > > > > > > > > > > > > I'm not sure this will work for all architectures of
> > > > > > > > > > > > > LNEs as
> > > > > > > > > > > > > well
> > > > > > > > > > > > > as
> > > > > > > > > > > > I don't understand, IMO it is not restrictive at all.
> > > > > > > > > > > > What kind
> > > > > > > > > > > > of
> > > > > > > > > > > > restrictions
> > > > > > > > > > > > do you see?
> > > > > > > > > > > > 
> > > > > > > > > > > > Lada
> > > > > > > > > > > > 
> > > > > > > > > > > > > Lou
> > > > > > > > > > > > > 
> > > > > > > > > > > > > > Thanks, Lada
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > the following text in sec. 3.2 of schema-mount-08
> > > > > > > > > > > > > > > is wrong
> > > > > > > > > > > > > > > for
> > > > > > > > > > > > > > > traditional
> > > > > > > > > > > > > > >       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
> > > > > > > > > > > > > > > instance tree,
> > > > > > > > > > > > > > > same mount
> > > > > > > > > > > > > > > impact on YANG library: the server could provide
> > > > > > > > > > > > > > > it in a
> > > > > > > > > > > > > > > reply
> > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > an
> > > > > > > > > > > > > > > operation,
> > > > > > > > > > > > > > > So my proposal is to move from YANG library as
> > > > > > > > > > > > > > > state data
> > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > an
> > > > > > > > > > > > > > > operation.
> > > > > > > > > > > > > > > It

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 16 Jan 2018 16:13:47 +0100 (CET)

Lou Berger <[email-masked]> wrote:
> modules using inline.

I think these still are covered.

> For example an LNE that is implemented using
> VMs which can be managed by the host at different times of the VMs
> really don't see how YL-bis has any bearing on this point and

Using the new proposed meta data annotation together with the new YL
means that SM can support the use case above also in an NMDA server.
I think the new proposed solution covers more use cases than the
previous solution.

Do you think that there is any use case that the proposed solution
cannot handle, but the previous solution did?

> I think
> it is incumbent upon those revisiting past/closed WG decisions (in
> this case, inline schema being represented by YL) to argue why the
> decision needs to be revisited.

I'm repeating my self: b/c the current solution doesn't work well with
the NMDA.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 16 Jan 2018 16:22:46 +0100

On Tue, 2018-01-16 at 16:13 +0100, Martin Bjorklund wrote:
> > >>>>>> It sounds like you are proposing in (1) a fairly significant change
> in
> > >>>>>> the

Yes, I think they are.

> I'm repeating my self: b/c the current solution doesn't work well with

We can try to update the draft and the examples, it should then be much more
clear. It is really very little extra work.

Lada

---

From: Lou Berger <[email-masked]>
Date: Tue, 16 Jan 2018 10:34:09 -0500

On 1/16/2018 10:13 AM, Martin Bjorklund wrote:
... (trimming to topic)
Martin,

you didn't respond to this point.

> I think the new proposed solution covers more use cases than the

how so?  The inline mount point would contain YL-bis and have the same 
information there, just scoped for the mount point.  It's true a client 
would need to understand the mount point's schema only upon parsing the 
YL under the mount point and this schema could not be shared across 
inline mount points.  But this is as was discussed in the past and 
unchanged from YL.

> cannot handle, but the previous solution did?
yes.  with VM/container technologies the YL / schema can change under 
the mount point from time to time during normal operation (i.e., during 
runtime, no reboot) and, in some implementations, may require some level 
of rpc operation to access even the schema.  The new (and previously 
proposed approach) of having inline schema available from the top level 
greatly complicates these cases.  Also keep in mind that there will be 
cases where the ability to access information under an inline mount 
point will dynamically change in operation (and top level YL would need 
to remove schema information for the inline mount point.)  As before, 
from the usage standpoint, these changes don't provide a whole lot of 
value and seem to optimizing for something not needed in the inline case.

> I'm repeating my self: b/c the current solution doesn't work well with
I simply don't understand how YL-bis works at the root node but doesn't 
work equally at an inline mount point.  Can you elaborate?

Lou

---

From: Lou Berger <[email-masked]>
Date: Tue, 16 Jan 2018 10:46:21 -0500

> clear. It is really very little extra work.

Lada,
     Understanding impact of your proposal on the following would be 
quite helpful:
https://datatracker.ietf.org/doc/draft-ietf-rtgwg-lne-model/ (pub requested)
https://datatracker.ietf.org/doc/draft-ietf-rtgwg-ni-model/ (pub requested)
https://datatracker.ietf.org/doc/draft-ietf-bess-l3vpn-yang/

Lou

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 16 Jan 2018 16:50:14 +0100 (CET)

> you didn't respond to this point.

I agree, it works for non-NMDA servers. But see below.

> information there, just scoped for the mount point.  It's true a
> client would need to understand the mount point's schema only upon
> parsing the YL under the mount point and this schema could not be
> shared across inline mount points.  But this is as was discussed in
> the past and unchanged from YL.
> 
> the mount point from time to time during normal operation (i.e.,
> during runtime, no reboot) and, in some implementations, may require
> some level of rpc operation to access even the schema.  The new (and
> previously proposed approach) of having inline schema available from
> the top level greatly complicates these cases.  Also keep in mind that
> there will be cases where the ability to access information under an
> inline mount point will dynamically change in operation (and top level
> YL would need to remove schema information for the inline mount
> point.)  As before, from the usage standpoint, these changes don't
> provide a whole lot of value and seem to optimizing for something not
> needed in the inline case.

I think this is an implementation issue, rather than a problem with
the proposed mechanism, and it is present in the current solution as
well.  An implementation that can handle dynamically changing mounted
YLs in the current solution can do that in the new solution as well.

> I simply don't understand how YL-bis works at the root node but
> doesn't work equally at an inline mount point.  Can you elaborate?

With NMDA, a server may have one schema for the config datastore and
another one for operational (one is a superset of the other).  A
mounted YL can only be present in operational.  Thus, there's no way a
client can learn the schema for config.

With the proposed solution, there can be different schema-ref pointers
in config and operational (if needed).

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 16 Jan 2018 16:55:50 +0100

On Tue, 2018-01-16 at 10:34 -0500, Lou Berger wrote:
> > > > > > > > > rejectected by the WG multiple times.  FWIW there are drafts
> > > > > > > > > already
> > > > > > > > > with
> > > > > > > > 
> > > > > > > > No at all. The first and last time I proposed this was on 15
> > > > > > > > December
> > > > > > > > 2017:
> > > > > > > > 

As Martin already wrote, this cannot be done for in config datastores.

> greatly complicates these cases.  Also keep in mind that there will be

Why? I assume that new schemas can be added as entries of the parent YL "schema"
list even at runtime. So you just do it, and change the @schema-ref leafref with
which the mount point instance undergoing the change is annotated.

> work equally at an inline mount point.  Can you elaborate?

I propose that we update the schema mount draft in a separate branch on GitHub,
and then continue the discussion.

Lada

---

From: Robert Wilton <[email-masked]>
Date: Tue, 16 Jan 2018 16:15:57 +0000

> client can learn the schema for config.
If the LNE mounted the full YL-bis at the mount point then you would 
have the list of datastores, and the schema associated with each 
datastore.  Of course, this would only be available in operational, but 
that is the same as a regular server support YL-bis.

I thought that the problem with the current solution and NMDA, was that 
there is no way to find out what the LNE schema is if the LNE isn't 
booted, and hence isn't providing <operational>.  But I'm not sure what 
issues that actually causes.  E.g. does it cause issues with 
pre-configuration of the LNE?

Thanks,
Rob

---

From: Lou Berger <[email-masked]>
Date: Tue, 16 Jan 2018 12:22:08 -0500

That's a fine idea, but ultimately we'll need to discuss/understand the 
impact to the other dependent drafts, including the two already with the 
IESG.  If you can look at those and comment now, that would be helpful.

Lou

---

From: Lou Berger <[email-masked]>
Date: Tue, 16 Jan 2018 12:32:08 -0500

> that is the same as a regular server support YL-bis.
exactly my point.

> booted, and hence isn't providing <operational>.
I've never heard anyone mention this issue/limitation.  My understanding 
of the previously raised objections were (a) that the full schema can't 
be obtained by just reading the top level YL and (b) that when multiple 
inline mount points have the same schema the information can't be 
combined using a shared schema approach as is taken in base SM.  Yes 
both increase client operations/work, but without incurring the server 
side implementation overhead that is implied in this approach.  -- 
Again, I don't see how YL-bis or NMDA changes any of this.

>   But I'm not sure what
Assignment of host resources takes place at the root level, not the 
within the context of the inline mount point, other preprovisiong can be 
handled via the inline/managed mechanisms defined in the LNE module.  We 
looked at this in detail for multiple server/vendor implementations and 
agreed the current mechanisms work even if not optimal in all cases.

Lou

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 17 Jan 2018 07:59:33 +0100

On Tue, 2018-01-16 at 16:15 +0000, Robert Wilton wrote:
> > > > > > > > > > > rejectected by the WG multiple times.  FWIW there are
> > > > > > > > > > > drafts already
> > > > > > > > > > > with
> > > > > > > > > > 

YL-bis is different in that it is in fact metadata even though we call it state
data. In any case, no matter what datastores the server has, YL-bis is the
single well-known location from which the schema of all datastores can be
retrieved.

We could refer to <operational> as the place from which the mounted schemas of
NMDA-standard config datastores can be retrieved (except for special cases, one
is discussed below). But if there is another config datastore (e.g. dynamic)
with an inline mount point instance, it is unclear where to look for the mounted
schema. With my proposal, the mount point instance will be annotated with
@schema-ref that points to a schema in the top-level YL.

> pre-configuration of the LNE?

The issue that this causes is that the schema for the pre-configured LNE isn't
known and validity of <intended> is unclear.

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 17 Jan 2018 09:04:29 +0100

> https://datatracker.ietf.org/doc/draft-ietf-rtgwg-ni-model/ (pub

In these two drafts, the examples in their appendices have to be updated.

> https://datatracker.ietf.org/doc/draft-ietf-bess-l3vpn-yang/

AFAICT, there is no impact on this draft.

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 17 Jan 2018 09:20:02 +0100 (CET)

> > that is the same as a regular server support YL-bis.

Yes, you're right.  But it requires the usage of YL-bis.

> I've never heard anyone mention this issue/limitation.

This has been dicussed, but this does not change with the introduction
of the meta annotation; if the server has off-line knowledge of the
instance's schema then it can populate an inline YL as well as the
meta annotation and corresponding SM data.

> My
> understanding of the previously raised objections were (a) that the
> full schema can't be obtained by just reading the top level YL and (b)
> that when multiple inline mount points have the same schema the
> information can't be combined using a shared schema approach as is
> taken in base SM.

Right.  Both these issues are addressed by using a meta annotation.

/martin

> Yes both increase client operations/work, but
> without incurring the server side implementation overhead that is
> implied in this approach.  -- Again, I don't see how YL-bis or NMDA
> changes any of this.
> 
> >   But I'm not sure what
> within the context of the inline mount point, other preprovisiong can
> be handled via the inline/managed mechanisms defined in the LNE
> module.  We looked at this in detail for multiple server/vendor
> implementations and agreed the current mechanisms work even if not
> optimal in all cases.
> 
> Lou
> 
> > Thanks,
> > Rob
> >
> >

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 17 Jan 2018 09:27:18 +0100

> AFAICT, there is no impact on this draft.

Ideally data models should be decoupled from the mechanics with which
the (datastore) schema is announced.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 17 Jan 2018 09:33:47 +0100

> the (datastore) schema is announced.

Agreed, and that's why the l3vpn draft is unaffected. The LNE and NI drafts
demonstrate in the appendices how the entire data model is constructed via
schema mount, so this would change.

Lada

---

From: Lou Berger <[email-masked]>
Date: Wed, 17 Jan 2018 09:09:08 -0500

On 1/17/2018 1:59 AM, Ladislav Lhotka wrote:
...
> data.
I couldn't agree more.  YL and SM are server metadata and are 
independent of any DS.  They could be accessed via any (as others have 
suggested), but we are currently choosing to access if via operational 
state.  With NMDA, I think personally think server meta data should have 
it's own DS.  This discussion has convinced me that the current proposed 
alternative, of accessing as operational data is flawed and even access 
via *any* DS is preferable.

> In any case, no matter what datastores the server has, YL-bis is the
That's a nice idea, but as was discussed in december, the direction 
being taken doesn't include SM so this statement isn't *currently* true.

> with an inline mount point instance, it is unclear where to look for the mounted
Why?  Is it unclear where to look for YL-bis in this case?  Why is SM 
any different than YL?

>   With my proposal, the mount point instance will be annotated with
right and as we thrashed out the last time we had discussed this with 
the whole WG, having inline schema available at the top level was not 
the preferred solution.

> known and validity of <intended> is unclear.
Please elaborate on what you see here as a problem.  Those working on 
LNE's (including myself) don't see an issue here.

Lou

---

From: Lou Berger <[email-masked]>
Date: Wed, 17 Jan 2018 09:17:17 -0500

> Right.  Both these issues are addressed by using a meta annotation.

But when we discussed this the last time having inline schema available 
at the top level (in the SM module), the general consensus was that 
having YL under inline was the preferred approach.  Lada stated that he 
didn't like the approach, but would go with the WG decision.  Why are we 
reopening this closed discussion -- many months after we closed the 
issue?  Most who contributed, notably users, have moved from SM assuming 
it's a solved problem.

At this point, I think the case needs to be made why the existing 
mechanisms in the draft are broken vs how they might be improved. My 
understanding is that there was one issue that could be clarified by the 
proposed text I included when restarting this discussion.

What else is *broken* in the current draft?

Lou

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 17 Jan 2018 15:42:05 +0100 (CET)

Lou Berger <[email-masked]> wrote:
> But when we discussed this the last time having inline schema
> available at the top level (in the SM module), the general consensus
> was that having YL under inline was the preferred approach.

What is new now is that we have an indirection; each instance has its
own pointer to the schema at the top level.  In the previous
discussion, having the schema at the top level implied that all
instances shared the same schema, and *that* was rejected.

> Lada
> stated that he didn't like the approach, but would go with the WG
> decision.  Why are we reopening this closed discussion -- many months
> after we closed the issue?  Most who contributed, notably users, have
> moved from SM assuming it's a solved problem.
> 
> understanding is that there was one issue that could be clarified by
> the proposed text I included when restarting this discussion.
> 

My main concern is actually the YL version.  I strongly think SM need
to use YL-bis rather that the old YL, so that it can support NMDA.

The implementation effort for supporting the new YL in clients and
servers is minimal, esp. when compared to the efforts involved in
supporting SM.

Adding an indirection is (for me) less important, but it has the
benefit of solving the two issues (a) and (b) above, and I haven't
seen any technical problem with it.

Do you have any technical concerns with using an annotation as an
indirection?

/martin

---

From: Lou Berger <[email-masked]>
Date: Wed, 17 Jan 2018 10:43:25 -0500

> instances shared the same schema, and *that* was rejected.

Indirection was possible at the previous time and is part of the current 
scheme Mount definition. Yes, you need to use different mount points to 
reference different schema, but take a look at the ni document that's 
exactly what we are doing there. So I don't believe this is the point that 
caused the previous proposal to be rejected.

> to use YL-bis rather that the old YL, so that it can support NMDA.

Right now to SM is independent of Yang Library version and can run with 
either. I certainly would expect use of Yang Library bis and nmda to have 
advantages.

> seen any technical problem with it.
(A) has implementation implications and those participating in the 
discussion at the time expressed as not being worth the cost.
I don't believe b was seen as a significant issue either.

> Do you have any technical concerns with using an annotation as an

The technicsl issue I have with the approaches the same one that was raised 
when debated previously, ie the implementation overhead of requiring inline 
schemas to be available at the top level.

>From a process perspective, I don't think it's fair to those who provided 
input or contributed in the past  in order to get scheme mount to satisfy 
their requirements to reopen something that is not broken. Particularly 
because a number of those contributors are implementers and users  who are 
now focused on other topics.

Lou

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 17 Jan 2018 17:06:14 +0100

> via *any* DS is preferable.

Yes, I would support an extra datastore.

> being taken doesn't include SM so this statement isn't *currently* true.

I assume SM is also part of metadata, so it would be in the same datastore as
YL.

> Why?  Is it unclear where to look for YL-bis in this case?  Why is SM 

NMDA requires that standard config data be also in <operational>, so if we have
a mount point instance in <intended>, there is (mostly) a corresponding instance
in <operational>, which is the place where the embedded YL can be found. I don't
think other non-standard datastores necessarily have this relationship with
<operational>.

> the whole WG, having inline schema available at the top level was not 

Because we didn't have the metadata annotation that can now refer from any
inline mount point instance to a schema that is placed at the top level. It is
just a simple indirection.

> LNE's (including myself) don't see an issue here.

Assume the "root" mount point for LNE is inline. Can you have a pre-provisioned
configuration for a LNE entry? If so, then I assume there is no corresponding
LNE entry in <operational>. If this is correct, then I don't see from where you
get the embedded YL instance. That is, <intended> may contain

  "ietf-logical-network-element:logical-network-element": [
    { "name": "foo",
      "root": { ... pre-provisioned config ... }
    },
    ...
  ]

But if the "foo" LNE isn't booted, then there is no "foo" entry in
<operational>, i.e. also no corresponding instance of the "root" mount point.

Is this reasoning flawed?

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 17 Jan 2018 17:18:17 +0100 (CET)

Lou Berger <[email-masked]> wrote:
> >> >>>>>>>>>>> Oh, I certainly would call you proposing that the schema for
> >> >>>>>>>>>>> inline
> >> >>>>>>>>>>> be
> >> >>>>>>>>>>> part of the rest of the schema Mount module well before
> >> >>>>>>>>>>> that. I'm
> >> >>>>>>>>>>> sure
> >> >>>>>>>>>> when all instances have the same schema.  This new proposal
> >> >>>>>>>>>> solves
> >> >>>>>>>>>> the
> Indirection was possible at the previous time and is part of the
> current scheme Mount definition. Yes, you need to use different mount
> points to reference different schema, but take a look at the ni
> document that's exactly what we are doing there. So I don't believe
> this is the point that caused the previous proposal to be rejected.
> 
> >> Lada
> Right now to SM is independent of Yang Library version and can run
> with either.

No this is not correct.  SM uses a grouping from the old YANG
library (for the "use-schema" case), and talks about mounting
"modules-state" ("inline" case).

> I certainly would expect use of Yang Library bis and nmda
> to have advantages.
> 
> The technicsl issue I have with the approaches the same one that was
> raised when debated previously, ie the implementation overhead of
> requiring inline schemas to be available at the top level.

Ok.  I'm ok with keeping the inline case as it is.  However, I think
we need to use the new YL-bis, so that we can support the NMDA.

/martin

> 
> From a process perspective, I don't think it's fair to those who
> provided input or contributed in the past in order to get scheme mount
> to satisfy their requirements to reopen something that is not
> broken. Particularly because a number of those contributors are
> implementers and users who are now focused on other topics.
> 
> Lou
> 
> >
> > /martin
> >
> 
>

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 17 Jan 2018 17:26:20 +0100

On Wed, 2018-01-17 at 10:43 -0500, Lou Berger wrote:
> > > > > > > > > > > > > > Oh, I certainly would call you proposing that the
> > > > > > > > > > > > > > schema for inline
> > > > > > > > > > > > > > be
> > > > > > > > > > > > > > part of the rest of the schema Mount module well
> > > > > > > > > > > > > > before that. I'm
> > > > > > > > > > > > > > sure
> > > > > > > > > > > > > were basically variants on what is now "use-schema",
> > > > > > > > > > > > > which works
> > > > > > > > > > > > > fine
> > > > > > > > > > > > > when all instances have the same schema.  This new
> > > > > > > > > > > > > proposal solves
> > > > > > > > > > > > > the

What Martin and I are talking about is a mount point that is a list node of the
"use-schema" type. There is no way how different entries of this list could have
different schemas.

The same applies to a container mount point that is inside a list. Then you can
also have multiple *instances* of the mount point, and with "use-schema" there
is no way how these instances could have different schemas.

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 17 Jan 2018 17:34:33 +0100

On Wed, 2018-01-17 at 17:18 +0100, Martin Bjorklund wrote:
> > > > > > > > > > > > > > > before
> > > > > > > > > > > > > > I don't think this has been proposed before.  All
> > > > > > > > > > > > > > previous
> > > > > > > > > > > > > > proposals
> > > > > > > > > > > > > > proposal
> > > > > > > > > > > > > I thought the previous proposals that as well, so
> > > > > > > > > > > > > don't see
> > > > > > > > > > > > > material
> > > > > > > > > > > > > difference - at least from the usage standpoint. I
> > > > > > > > > > > > > also don't see
> > > > > > > > > > > > > why
> > > > > > > > > > > > B/c it doesn't work well with the NMDA.  You can't mount
> > > > > > > > > > > > yang
> > > > > > > > > > > > library
> > > > > > > > > > > Understood and agree there is nothing new here and the
> > > > > > > > > > > current
> > > > > > > > > > > version
> > > > > > > > > > I'm repeating my self: b/c the current solution doesn't work
> > > > > > > > > > well
> > > > > > > > > > with
> > > > > > > > > > the NMDA.
> > > > > > > > > 
> > > > > > > datastore.  Of course, this would only be available in
> > > > > > > operational,
> > > > > > > but

Could you specify where this overhead comes from? Does it matter whether you
place some data inside the data tree or somewhere at the top level and point to
it from inside the tree?

> Ok.  I'm ok with keeping the inline case as it is.  However, I think

I don't agree. The metadata annotation solves real issues.

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 17 Jan 2018 17:40:39 +0100 (CET)

> I don't agree. The metadata annotation solves real issues.

One issue with the annotation is that since the schema might be
different in different datastores, it means that the client needs to
read the annotation in all datastores, and then fetch the schemas.  So
it is a bit more difficult to work with for a client.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 17 Jan 2018 17:57:46 +0100

On Wed, 2018-01-17 at 17:40 +0100, Martin Bjorklund wrote:
> > > > > > > > > > > > > > > > > > > rejectected by the WG multiple times. 
> FWIW
> > > > > > > > > > > > > > > > > > > there are drafts
> > > > > > > > > > > > > > > > > > > already
> > > > > > > > > > > > > > > > > > > with
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > No at all. The first and last time I
> proposed
> > > > > > > > > > > > > > > > > > this was on 15
> > > > > > > > > > > > > > > > > > December
> > > > > > > > > > > > > > > > > > 2017:
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > https://www.ietf.org/mail-archive/web/netmod
> /cur
> > > > > > > > > > > > > > > > > > rent/msg19753.html
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > the previous arguments that resulted in consensus
> for
> > > > > > > > > > > > > > > using Yang
> > > > > > > > > > > > > > > Library underneath the an in line Mount Point
> don't
> > > > > > > > > > > > > > > apply.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > in the configuration datastores; it has to be
> mounted in
> > > > > > > > > > > > > > operational.
> > > > > > > > > > > > > expect it to behave the same once we have rfc7985bis
> -- in
> > > > > > > > > > > > > fact the
> > > > > > > > > > > > > The argument I recall being the key point on inline
> was
> > > > > > > > > > > > > handling the
> > > > > > > > > > > > > VMs which can be managed by the host at different
> times of
> > > > > > > > > > > > > the VMs
> > > > > > > > > > > > > really don't see how YL-bis has any bearing on this
> point
> > > > > > > > > > > > > and
> > > > > > > > > > > > 
> > > > > > > > > > > > Using the new proposed meta data annotation together
> with
> > > > > > > > > > > > the new YL
> > > > > > > > > > > > means that SM can support the use case above also in an
> NMDA
> > > > > > > > > > > > server.
> > > > > > > > > > > > I think the new proposed solution covers more use cases
> than
> > > > > > > > > > > > the
> > > > > > > > > > > > previous solution.
> > > > > > > > > > > 
> > > > > > > > > > > how so?  The inline mount point would contain YL-bis and
> have
> > > > > > > > > > > the same
> > > > > > > > > > > information there, just scoped for the mount point.  It's
> true
> > > > > > > > > > > a
> > > > > > > > > > > client would need to understand the mount point's schema
> only
> > > > > > > > > > > upon
> > > > > > > > > > > parsing the YL under the mount point and this schema could
> not
> > > > > > > > > > > be
> > > > > > > > > > > > Do you think that there is any use case that the
> proposed
> > > > > > > > > > > > solution
> > > > > > > > > > > during runtime, no reboot) and, in some implementations,
> may
> > > > > > > > > > > require
> > > > > > > > > > > some level of rpc operation to access even the schema. 
> The
> > > > > > > > > > > new (and
> > > > > > > > > > > the top level greatly complicates these cases.  Also keep
> in
> > > > > > > > > > > mind that
> > > > > > > > > > > there will be cases where the ability to access
> information
> > > > > > > > > > > under an
> > > > > > > > > > > inline mount point will dynamically change in operation
> (and
> > > > > > > > > > > top level
> > > > > > > > > > > point.)  As before, from the usage standpoint, these
> changes
> > > > > > > > > > > don't
> > > > > > > > > > I think this is an implementation issue, rather than a
> problem
> > > > > > > > > > with
> > > > > > > > > > well.  An implementation that can handle dynamically
> changing
> > > > > > > > > > mounted
> > > > > > > > > > YLs in the current solution can do that in the new solution
> as
> > > > > > > > > > well.
> > > > > > > > > > 
> > > > > > > > > > > > > I think
> > > > > > > > > > > > > this case, inline schema being represented by YL) to
> argue
> > > > > > > > > > > > > why the
> > > > > > > > > > > I simply don't understand how YL-bis works at the root
> node
> > > > > > > > > > > but
> > > > > > > > > > With NMDA, a server may have one schema for the config
> datastore
> > > > > > > > > > and
> > > > > > > > > > mounted YL can only be present in operational.  Thus,
> there's no
> > > > > > > > > > way a
> > > > > > > > > I thought that the problem with the current solution and NMDA,
> was
> > > > > > > > > that
> > > > > > > > full schema can't be obtained by just reading the top level YL
> and
> > > > > > > > (b)

But it doesn't mean that the schemas *must* be different, and it is easy to
figure out when they are the same. Also, modules sets in YLbis can further help
avoid redundant parsing of the same modules.

Lada

---

From: Lou Berger <[email-masked]>
Date: Wed, 17 Jan 2018 13:57:26 -0500

> Is this reasoning flawed?
Yes.  At least the YL would be instantiated under operational because 
that's where it (server metadata) *always* goes.

Lou

---

From: Lou Berger <[email-masked]>
Date: Wed, 17 Jan 2018 14:10:01 -0500

On 1/17/2018 11:26 AM, Ladislav Lhotka wrote:
>>> instances shared the same schema, and*that*  was rejected.
>>>
> also have multiple*instances*  of the mount point, and with "use-schema" there
umm, if a server knows enough to use the right metadata indirection (per 
current proposal), it would have also know enough to use the right mount 
point and use-schema (in the old proposal).  Again, the latter is what 
we're doing to solve this *exact* problem for the non-inline case in the 
NI draft.

The only thing new in the proposal is how to encode the indirection, it 
doesn't change the fundamental points/discussion from when we decided on 
the current solution.

Lou

---

From: Lou Berger <[email-masked]>
Date: Wed, 17 Jan 2018 14:14:52 -0500

On 1/17/2018 11:57 AM, Ladislav Lhotka wrote:
> But it doesn't mean that the schemas*must*  be different, and it is easy to

So I think this amplifies that the difference is one of optimization.   
Given the maturity of this work and the state of the dependent work, 
some of which is already with IESG for publication - I don't see how or 
why we should be discussing anything more than fixing flaws in this 
document.

Lou

---

From: Lou Berger <[email-masked]>
Date: Wed, 17 Jan 2018 14:03:58 -0500

On 1/17/2018 11:18 AM, Martin Bjorklund wrote:
...
> library (for the "use-schema" case),
I thought YLbis was an updat e to UL (i.e., no name change) as such SM 
can include either.

>   and talks about mounting
In informative descriptions only.  Certainly these can be changed to 
allow for YL-bis if need be.

> we need to use the new YL-bis, so that we can support the NMDA.
Given that NMDA support is not yet fully defined, we're still in the 
transition period where support for both NMDA and non-NMDA 
implementations need to be considered.  Rob presented some options 
earlier in the thread that I think captures this.

Lou

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 17 Jan 2018 21:05:56 +0100

> why we should be discussing anything more than fixing flaws in this 

I beg to differ.

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 18 Jan 2018 08:56:48 +0100 (CET)

> I thought YLbis was an updat e to UL (i.e., no name change) as such SM

The old "modules-state" structure is deprecated, and a new structure
that allows multiple datastores is defined.  Note that YLbis can be
used by both NMDA-capabale and non-NMDA-capabale servers.

> earlier in the thread that I think captures this.

Again, note that YLbis supports both NMDA and non-NMDA servers.

Also note that YLbis is just a different read-only monitoring
structure.  Given an implementation that supports the old YL, it is
trivial to add support for YLbis (especially compared to the more than
non-trivial amount of work required to support schema mount...).

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 18 Jan 2018 09:12:32 +0100

> used by both NMDA-capabale and non-NMDA-capabale servers.

This is another reason to switch to the @schema-ref annotation, because
otherwise YLbis is unnecessarily complex and inefficient to be used under each
inline mount point instance, with the module-sets and datastore lists.

Lada

---

From: Lou Berger <[email-masked]>
Date: Thu, 18 Jan 2018 07:58:07 -0500

Martin,

I do agree with that at some point we will need to revisit scheme mount in 
the context of YL-bis, as there are different possible solutions for 
handling different datastores mounting  different schema. I think Rob laid 
out the options pretty well here, ie doing it now or publishing as is and 
immediately working on the document that covers both.

As I mentioned before I think this is as much a process issue as anything 
else - and have a planned call to discuss possible directions with chairs. 
I hope we can have some propose next steps on this to the working group in 
short order.

Lou

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 18 Jan 2018 14:39:20 +0100

Ignoring process issues (not sure there are any), does it make sense
to publish a YANG module on the standards-track that is replaced by
something different 3-6 months later?

Note that the NMDA contributors, after getting the overall design
done, move sequentially through the details of the documents; we first
focused on the NMDA document, which is in the RFC editor queue now. We
then focussed on the protocol extensions, which are now in WG last
call. Currently we are focusing on getting the new yang library
finalized. If no major isses pop up, the NMDA work may be complete by
the London IETF. Hence the 3 months lower bound mentioned above.

/js

On Thu, Jan 18, 2018 at 07:58:07AM -0500, Lou Berger wrote:
> else - and have a planned call to discuss possible directions with chairs. I
> hope we can have some propose next steps on this to the working group in
> short order.
> 
> Lou
> 
>

---

From: joel jaeggli <[email-masked]>
Date: Thu, 18 Jan 2018 08:25:35 -0800

> something different 3-6 months later?

Perhaps I apply a different discount rate on the future particularly
when timelines are involved. e.g. 3 months turns into a year and half
pretty quickly.

I think it's more a question of can we live with publishing the module
now as is? Or can  we not live with publishing it now?

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 18 Jan 2018 18:31:53 +0100

> when timelines are involved. e.g. 3 months turns into a year and half

I provided a reasoning why 3 months may be feasible, I doubled it
since its the IETF. You may apply the factor 6. But note that the last
piece of NMDA (the YANG library) is work reasonably well understood
with people dedicated to finish the last piece (obviously my very
biased view).

> now as is? Or can  we not live with publishing it now?

The question is what we expect implementors to do and how we think
about achieving interoperability by publishing two significantly
different versions instead of one.

/js

---

From: Kent Watsen <[email-masked]>
Date: Thu, 18 Jan 2018 18:30:49 +0000

> with people dedicated to finish the last piece (obviously my very

I believe the issue isn't so much the timing on the YANG Library bis,
so much as the timing on having an updated schema-mount draft that 
is NMDA-compatible.

> different versions instead of one.

Agreed, we will need to provide guidance with this approach.

Kent // nobody

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 18 Jan 2018 20:10:37 +0100

> something different 3-6 months later?

IMO such a document churn would be a serious mistake. In the documents that are
currently on the table (at least NMDA, YLbis, SM) we are dealing with quite a
few tricky and interrelated things, so it's important to come up with a coherent
view into which all the components nicely fit. And I believe we are now quite
close.

Publishing an interim solution that is a priori known to be technically inferior
would just confuse people. The fact that it can be hacked to support two or
three particular data models (albeit important) doesn't warrant to do so.

> the London IETF. Hence the 3 months lower bound mentioned above.

I agree, and will try to help.

Thanks, Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 18 Jan 2018 20:15:35 +0100 (CET)

> three particular data models (albeit important) doesn't warrant to do so.

I strongly agree with this!

/martin

---

From: joel jaeggli <[email-masked]>
Date: Thu, 18 Jan 2018 13:25:10 -0800

> I strongly agree with this!
Do we believe that documents using normative referencing to this draft
e.g. in routing would require changes in order to accommodate an updated
draft?

If yes then we're doing ourselves a clear dis-service by essentially
clearing the boards of the existing draft.  If that is the case we
should consider publishing this one possibly with an appropriate
applicability statement; the work on the new one can proceed so that at
least they have a stable reference. This assumes not fundamental flaws
that make the current one unusable.

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 19 Jan 2018 07:50:10 +0100

> e.g. in routing would require changes in order to accommodate an updated

As I wrote, the LNE and NI documents will have to update the examples in their
(non-normative) appendices. Drafts that just define specific YANG modules
shouldn't be affected even if they use schema mount.

It is IMO not a big deal.

Lada

> > > > > > > > > > My main concern is actually the YL version.  I strongly
> > > > > > > > > > think SM
> > > > > > > > > > need

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 19 Jan 2018 09:58:41 +0100 (CET)

Hi,

joel jaeggli <[email-masked]> wrote:
> clearing the boards of the existing draft.

As Lada wrote earlier, two of the three drafts need updated *examples*
in their appendicies.  They do not need any changes to their normative
sections.

> If that is the case we

Since some time back, we require all drafts to be NMDA compliant.  Why
should SM be different?  Note that this solution does not *require*
NMDA.

One reason for SM being late is that it has been difficult to find a
technical solution for which even the authors could agree.  The
current draft is a compromise.  By using YLbis we can solve some of
these issues, and since this is a central building block I think it
would be very unwise to publish it just to avoid updating two
examples.

/martin

---

From: Lou Berger <[email-masked]>
Date: Fri, 19 Jan 2018 10:13:24 -0500

Martin,

Managing transitions is always a challenge. Also coming up with a consensus 
solutions often involves compromise which will sometimes challenge 
enthusiasm for support of the solution. Unfortunately, schema mount hits 
both of these challenges.

>From the compromise standpoint, we've had parties basically negotiate over 
a period of 2 years on a solution that both accepted is workable. I know 
that the users of the draft explicitly decided that the documented solution 
was good enough for their needs and it was preferable to move forward then 
continue debating for their preferred changes.

>From the transition standpoint we have a document that completed last call 
months ago with only minor issues being raised. It is true that the current 
document doesn't support different schemas in different data stores, in all 
but one case, and this limitation should certainly be documented. But from 
the process standpoint, it's rather hard to say that we should not move 
forward with a post last call document in deference to an alternative that 
has yet to be documented, debated, or whose impact can be fully analyzed.

Lou

On January 19, 2018 3:59:22 AM Martin Bjorklund <[email-masked]> wrote:
...

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 19 Jan 2018 17:47:37 +0100 (CET)

Lou Berger <[email-masked]> wrote:
> Martin,
> 
> Managing transitions is always a challenge. Also coming up with a
> consensus solutions often involves compromise which will sometimes
> challenge enthusiasm for support of the solution. Unfortunately,
> schema mount hits both of these challenges.
> 
> From the compromise standpoint, we've had parties basically negotiate
> over a period of 2 years on a solution that both accepted is
> workable. I know that the users of the draft explicitly decided that

Note that nothing changes for other documents if we use YLbis (except
for updating some examples, as Lada noted).  Also note that there are
other users than other WGs (vendor implementations).

Yes, it may add a few more weeks to the publication process, but I
definitely think it is worth it.  As you wrote, we've been working
on this for a couple of years, so waiting a few more weeks should be
ok.

I note that you didn't reply to my question about why this document is
different compared to all other documents that we require to be
NMDA-compliant.

/martin

> the documented solution was good enough for their needs and it was
> preferable to move forward then continue debating for their preferred
> changes.
> 
> From the transition standpoint we have a document that completed last
> call months ago with only minor issues being raised. It is true that
> the current document doesn't support different schemas in different
> data stores, in all but one case, and this limitation should certainly
> be documented. But from the process standpoint, it's rather hard to
> say that we should not move forward with a post last call document in
> deference to an alternative that has yet to be documented, debated, or
> whose impact can be fully analyzed.
> 
> Lou
>

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 19 Jan 2018 18:04:26 +0100

Hi Lou,

> both of these challenges.

Transition problems is what we would create by publishing the current revision
of SM now and another in a couple of months. It would most likely mean keeping
some annoying baggage like obsolete nodes that only confuse readers. We can and
should avoid this.

> but one case, and this limitation should certainly be documented. But from

For me, it is not so much about limitations but rather about architecture, i.e.
good design of metadata that describe the overall data model. If it is messy
with gaps covered by hand-waving statements, nobody will understand it.

Lada

> > > > > IMO such a document churn would be a serious mistake. In the
> > > > > documents 
> > > 
> > > that are
> > > > > currently on the table (at least NMDA, YLbis, SM) we are dealing with 
> > > 
> > > quite a
> > > > > few tricky and interrelated things, so it's important to come up with
> > > > > a 
> > > 
> > > coherent
> > > > > view into which all the components nicely fit. And I believe we are
> > > > > now 
> > > 
> > > quite
> > > > > close.
> > > > > 
> > > > > Publishing an interim solution that is a priori known to be
> > > > > technically 
> > > 
> > > inferior
> > > > > > > else - and have a planned call to discuss possible directions
> > > > > > > with 
> > > 
> > > chairs. I

---

From: Robert Wilton <[email-masked]>
Date: Fri, 19 Jan 2018 18:05:15 +0000

> Ladislav Lhotka <[email-masked]> wrote:

<snip>

> it is a bit more difficult to work with for a client.
I'm still not convinced that I really understand all the arguments here:

Using YLbis over YL seems to have obvious benefits to me, in that I 
perceive that it gives a cleaner data model.  But I also understand 
Lou's concerns - although its not clear to me whether Lou's primary 
concern is timing, or the fact that implementations are forced to use YLbis.

I also agree with Juergen that from an YLbis authors perspective YLbis 
is quite close.  I believe that the YANG model itself has been agreed 
(at the interim meeting in Nov/Dec), and hence really what is left is 
just tidying/enhancing the descriptive text in the document.

I don't really understand the benefits of the metadata annotations. It 
feels like this is going to be more hassle because a client will have to 
query each datastore separately rather than getting the information in a 
single operation.

A regular (without SM) NMDA NC/YANG server supports multiple datastores, 
but that information is only exposed via one so them (i.e. 
<operational>).  So, in a server supporting inline SM, it seems quite 
natural to me for the mounted schema information to also only be 
available via the mounted <operational>.  This seems to mirror the 
standard NC/YANG+YL behavior, and also seems to naturally recurse if 
required.

Hence, for me, I see the choice as:
1) do we publish the existing model now (perhaps also mark the draft as 
experimental) followed by an updated draft with the NMDA compatible module?
2) do we publish both models in a single draft (e.g. with the existing 
model in an appendix)?
3) do we only publish a single version of the draft with an NMDA 
compliant solution.

Thanks,
Rob

---

From: Lou Berger <[email-masked]>
Date: Fri, 19 Jan 2018 14:00:59 -0500

Rob,

On January 19, 2018 1:05:46 PM Robert Wilton <[email-masked]> wrote:

> perceive that it gives a cleaner data model. 

It is worth noting that the current scheme amount document can be used 
either with young library or Young Library BIS.

> But I also understand

My concern is the delay required to reach consensus  on an unspecified 
solution that has not been discussed and may contain unknown implications. 
Keep in mind that where we are today has required compromises. Just because 
we have one party that understands what they think they're going to write 
doesn't mean that there will be changes as details are worked out, and as 
consensus is obtained.

> available via the mounted <operational>. 

It also enables and implementation of the current SM document to support 
nmda data stores under a inline Mount point.

> This seems to mirror the

There are certainly a few variants possible, but the fundamental choice is 
to go ahead with basically what passed last call or not.

Lou

---

From: Dean Bogdanovic <[email-masked]>
Date: Sat, 20 Jan 2018 17:16:40 -0500

As Lou mentioned, schema mount can be used with or without YANG library. As author who uses the schema mount in a draft and in product, don’t want to hold back the publication. We, IETF, are too slow. Getting data model RFCs published takes too much time and we are not getting experience from implementation and operational usage. Things have to move much faster or the industry will move away from this organization. At the end, if we need to we can revise to support future publications. 

Dean

> On Jan 19, 2018, at 2:00 PM, Lou Berger <[email-masked]> wrote:
> 
> Rob,
> 
> 
> It is worth noting that the current scheme amount document can be used either with young library or Young Library BIS.
> 
>> But I also understand
> My concern is the delay required to reach consensus  on an unspecified solution that has not been discussed and may contain unknown implications. Keep in mind that where we are today has required compromises. Just because we have one party that understands what they think they're going to write doesn't mean that there will be changes as details are worked out, and as consensus is obtained.
> 
> 
> It also enables and implementation of the current SM document to support nmda data stores under a inline Mount point.
> 
>> This seems to mirror the
> There are certainly a few variants possible, but the fundamental choice is to go ahead with basically what passed last call or not.
> 
> Lou
> 
>> Thanks,
>> Rob
>> 
>> 
>> 
> 
>

---

From: Kent Watsen <[email-masked]>
Date: Sat, 20 Jan 2018 23:44:20 +0000

Hi Dean,

"As Lou mentioned, schema mount can be used with or without YANG library. As author who uses the schema mount in a draft and in product, don’t want to hold back the publication. We, IETF, are too slow. Getting data model RFCs published takes too much time and we are not getting experience from implementation and operational usage. Things have to move much faster or the industry will move away from this organization. At the end, if we need to we can revise to support future publications."

Just a clarification on your last sentence, my understanding is that a revision is necessary in order for schema-mount to work on NMDA-based servers.  Should we publish the current draft as is now, we're effectively committed to publishing an NMDA-update in the near-term anyways.

Kent

---

From: Kent Watsen <[email-masked]>
Date: Sun, 21 Jan 2018 00:54:10 +0000

Dean writes: "<snip/> At the end, if we need to we can revise to support future publications."

I write: "Just a clarification on your last sentence, my understanding is that a revision is necessary in order for schema-mount to work on NMDA-based servers.  Should we publish the current draft as is now, we're effectively committed to publishing an NMDA-update in the near-term anyways."

Lou's correcting me off-list.  He says that current solution can be used on NMDA servers, albeit with the with disclaimer that all non-inline schema must be the same for all datastores.  Okay, this lets some steam off, maybe we don't have to update it right away, Dean's statement is accurate.  But I imagine that we'll get around to it sooner or later, so it doesn't change there being an update at some point.  

I think what I'm missing is how big up an upset would it be?  Can the authors please sketch out what the NMDA-oriented update would look like?  Would it, for instance, manifest as a revision to the existing module or a new module and, if it were a new module, would it be possible for a server to implement both the old and new modules simultaneously without causing problems?

Kent

_______________________________________________
netmod mailing list
[email-masked]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=bezCPxTAzOuCjw3RWke7N9NOnRr44my9qVBtYe4a0mA&s=frWVRPVlyAcPAQl-ARNvCYiYw-euPz6l-23lU9HSQCU&e=

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 22 Jan 2018 12:13:18 +0100

On Fri, Jan 19, 2018 at 06:05:15PM +0000, Robert Wilton wrote:
> 2) do we publish both models in a single draft (e.g. with the existing model
> in an appendix)?
> 3) do we only publish a single version of the draft with an NMDA compliant
> solution.
>

I think the situation is as follows (likely obvious but it may help to
make sure we are all on the same page):

- the NI and LNE models have a normative reference to
  I-D.ietf-netmod-schema-mount (and this makes sense since there are
  MUST sentences in the I-D)

- I-D.ietf-netmod-schema-mount (last updated in October) has normative
  references to RFC 7895 (old YANG library)

- RFC 7895 does not work with NMDA, NMDA work on a YANG library update
  replacing RFC 7895

So the YANG library update is gating the schema mount update which is
gating the publication of the NI and LNE models.

A proper solution would be to prioritize work on the YANG library
update and the schema mount update. I assume that the next revision of
the YANG library update (say end of January) is ready for WG last call
and perhaps the schema mount authors can take an effort to get that
document there as well, say beginning of February.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 22 Jan 2018 14:35:49 +0100

> concern is timing, or the fact that implementations are forced to use

Note that it is only the migration to YLbis that implies changes in the
appendices of LNE and NI. The metadata annotation for inline mount
points doesn't require any change in any existing draft I am aware of.

> I don't really understand the benefits of the metadata annotations. It

My take is this:

Section 3.2 currently requires that "every instance of the [inline]
mount point that exists in the parent tree MUST contain a copy of YANG
library data". This was indeed the original idea that however doesn't
work with NMDA.

Lou's suggestion was that for inline mount point instances in
configuration datastores, the (embedded) YANG library will be available
under the corresponding mount point instance in <operational>. The
problem with this is that the corresponding instance needn't always
exist because

- NMDA mentions situations (e.g pre-provisioning) where an instance in
  <intended> has no corresponding instance in <operational>

- Only "base" NMDA config datastores are required to keep a copy of
  their data in <operational>. Other datastores IMO needn't follow this
  rule, or the relationship with <operational> needn't be so
  straightforward.  

Lou argued that this is not a problem for LNE and NI, but I think it is
not sufficient provided that schema mount is intended as a general
mechanism.

The metadat annotation solves this. Moreover, it allows for keeping all
schema-related metadata in one place that we can possibly think of as a
metadata datastore.

A use-schema-type mount point will then have a leafref to the mounted
schema directly in the metadata (i.e. fixed at implementation time)
whereas every instance of an inline-type mount point supplies the
same leafref at run time via the annotation. This is IMO a much cleaner
architecture.  

> query each datastore separately rather than getting the information in a 

But then the client would get schemas for all datastores, even those it
is not interested in.

Assume we have an inline mount point "root" (a container), and let's say
the schema for all NMDA config datastores is the same but <operational>
has a different schema. The *all* config datastores will contain just this
instance:

    <root schema-ref="root-schema">

and <operational> can have

    <root schema-ref="root-oper-schema">

Thanks to module sets in YLbis this can be expressed very efficiently
and I don't see how this could be a hassle for a client.

> standard NC/YANG+YL behavior, and also seems to naturally recurse if 

Not really. The difference is that the regular YL is unconditionally
present in a fixed location in <operational>. In contrast, to get the
embedded YL for an inline mount point instance in a config datastore, it
is necessary to determine a corresponding mount point instance in
<operational>, which is IMO not always possible. The metadata annotation
will point to the appropriate schema right away from the config datastore. 

> 3) do we only publish a single version of the draft with an NMDA 

I support #3.

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 22 Jan 2018 14:39:11 +0100

Kent Watsen <[email-masked]> writes:

> Just a clarification on your last sentence, my understanding is that a
> revision is necessary in order for schema-mount to work on NMDA-based
> servers.  Should we publish the current draft as is now, we're
> effectively committed to publishing an NMDA-update in the near-term
> anyways.

Yes, and also keeping some deprecated nodes from the old version, which
would make the new model hard to read. This is IMO too high a price.

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 22 Jan 2018 14:45:36 +0100

> document there as well, say beginning of February.

I completely agree.

Lada

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 22 Jan 2018 16:18:15 +0000

Hi Lada, 

My primary concern is that the YANG Schema Mount delay will not only hold the NI/LNE but all the models that are dependent on them (e.g., L2VPN and L3VPN). This is for a document that has already finished WG Last Call. Additionally, your estimate for the size of the change and time to reach standardization is based on there being immediate consensus on the changes. This is probably overly optimistic given there was discussion on the proposed YANG Library BIS changes. I’d vote to publish the existing draft. 

In any case, being able to see the proposed changes ASAP is critical. 

Thanks,
Acee

On 1/22/18, 8:45 AM, "netmod on behalf of Ladislav Lhotka" <[email-masked] on behalf of [email-masked]> wrote:

    
    I completely agree.
    
    Lada

---

From: Jeff Tantsura <[email-masked]>
Date: Mon, 22 Jan 2018 08:21:23 -0800

+1, with Acee

Cheers,
Jeff

On 1/22/18, 08:18, "netmod on behalf of Acee Lindem (acee)" <[email-masked] on behalf of [email-masked]> wrote:

    Hi Lada, 

    
    Thanks,
    Acee

        
        
        I completely agree.
        
        Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 22 Jan 2018 17:44:57 +0100

Acee,

the documents that have already finished WG Last Call have a normative
reference on schema mount, which has not yet finished WG Last Call as
far as I recall. I think the RFC editor does not publish a document
with a missing normative reference. I continue to believe that the
time difference between doing the right thing and doing something
faster using definition we are in the process to deprecate is really
small. But of course, I may be entirely wrong.

/js

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 22 Jan 2018 16:58:15 +0000

It was WG Last Call’ed: https://mailarchive.ietf.org/arch/msg/netmod/csUvs6408En0yY-vapyU3IFcJqQ

And it was closed: https://mailarchive.ietf.org/arch/msg/netmod/gbXE4Le1I_3Y5oaNnpjYoZZZ4lw

However, it may not have ever completed.

Thanks,
Acee 

On 1/22/18, 11:45 AM, "Juergen Schoenwaelder" <[email-masked]> wrote:

    Acee,

    /js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 22 Jan 2018 18:44:45 +0100

Thanks. The longer WG last call thread started with Rob's message in
which he also asked about alignment with the YANG library update
(posted November 2nd). So the document is in a limbo state since
November 6th.

/js

---

From: Andy Bierman <[email-masked]>
Date: Mon, 22 Jan 2018 15:46:21 -0800

Hi,

> (posted November 2nd). So the document is in a limbo state since

Can somebody please answer some simple questions:

Q1) why can't SM use augment to add objects to YLbis?

Q2)  why should readers/developers of YLbis need to know
about SM if their implementations do not support SM at all?

Q3) Is there a msg in the email archive that explains the reasons that
YLbis needs to be delayed? Where is the concrete proposal to add
specific objects to YLbis?

/js

Andy

> > And it was closed: https://mailarchive.ietf.org/
> arch/msg/netmod/gbXE4Le1I_3Y5oaNnpjYoZZZ4lw
> >
> >     > My primary concern is that the YANG Schema Mount delay will not
> only hold the NI/LNE but all the models that are dependent on them (e.g.,
> L2VPN and L3VPN). This is for a document that has already finished WG Last
> Call. Additionally, your estimate for the size of the change and time to
> reach standardization is based on there being immediate consensus on the
> changes. This is probably overly optimistic given there was discussion on
> the proposed YANG Library BIS changes. I’d vote to publish the existing
> draft.
> >     >
> >     > On 1/22/18, 8:45 AM, "netmod on behalf of Ladislav Lhotka" <
> [email-masked] on behalf of [email-masked]> wrote:
> >     >

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 23 Jan 2018 08:34:56 +0100 (CET)

> Q1) why can't SM use augment to add objects to YLbis?

The idea is that SM augments YLbis; this is what we argue should be
done now.

> about SM if their implementations do not support SM at all?

They don't.  The idea is to put all SM-related stuff in SM.  No
changes to YLbis.

> specific objects to YLbis?

YLbis does not need to be delayed.  We hope it can advance quickly.

/martin