Subject: [netmod] Proposal for minimalist full NMDA support in schema mount

From: Lou Berger <[email-masked]>
Date: Thu, 22 Feb 2018 11:18:38 -0500

Hi,

(I have a bunch of different roles WRT this work.  This mail is being 
sent as an individual - as chair, I fully support the previous chair 
statements on this draft.)

Chris and I have come up with a proposal on how to provide full NMDA as 
part the existing schema-mount module.  Our motivation was to enable 
full NMDA support with *minimal* change to the model and disruption to 
the LC'ed work.  The key NMDA limitation, with -08, that we are aiming 
to address is the ability to support different mounted schema in 
different datastores for non-inline mount points. (See more detailed 
description below if interested full nuances of limitations of -08)

What we came up with was  to simply add a (leaf)list to identify in 
which datastores a
schema-mount schema is valid/present. This is somewhat similar to YL-bis 
schema/module-set. Specifically we're proposing (see below for full tree 
below):

            +--ro schema* [name]
               +--ro name           string
ADD          +--ro datastore*    ds:datastore-ref {revised-datastores}

This approach has the advantages of supporting different mounted schema 
in different DSes, working with both NMDA and non-NMDA implementations, 
supporting all of the extensively discussed features of schema mount 
(including recursive mounts), and having minor/scoped impact on all 
dependent work.  The main downside is that it isn't the most 
optimal/compact solution possible if we were to base this work on 
YL-bis/pre09 draft.  Of course -08 isn't necessarily optimal from all 
perspectives, but it is what was agreed to as sufficient by those who 
contribute to the WG discussion.

In short, we see this as a solution to  addresses the raised last call 
issue with the minimal impact on -08 and dependent work -- which is what 
is appropriate given where we are in the process.

So our/my question really is:

     Is this a solution that you/all can live with?

Note: optimization, design preference and perfect alignment with use or 
YL-bis are not part of our question as we both don't think that is the 
right question given where we are in the WG process.

Lou (with ideas developed with Chris, and chair hat off)

======
Details -- for those who want
======
As background, my understanding/view is that the -08 version of the both 
NMDA and non-NMDA supporting implementations, but there are limitations 
in its NMDA applicability. Used with Yang Library, [rfc7895], only 
non-NMDA implementations can be supported.  When used with the revised 
Yang Library defined in [I.D.ietf-netconf-rfc7895bis-],  NMDA 
implementations  can be supported with certain limitations. 
Specifically, this document requires use of the now deprecated 
module-list grouping, and the same schema represented in schema list of 
the Schema Mount module MUST be used in all datastores.  Inline type 
mount points, which don't use the schema list,  can support different 
schema in different data stores not by instantiating the 
[I.D.ietf-netconf-rfc7895bis-] version of YANG library under the inline 
mount point.

     module: ietf-yang-schema-mount
         +--ro schema-mounts
            +--ro namespace* [prefix]
            |  +--ro prefix    yang:yang-identifier
            |  +--ro uri?      inet:uri
            +--ro mount-point* [module name]
            |  +--ro module        yang:yang-identifier
            |  +--ro name          yang:yang-identifier
            |  +--ro config?       boolean
            |  +--ro (schema-ref)?
            |     +--:(inline)
            |     |  +--ro inline?       empty
            |     +--:(use-schema)
            |        +--ro use-schema* [name]
            |           +--ro name
            |           |       -> /schema-mounts/schema/name
            |           +--ro parent-reference*   yang:xpath1.0
            +--ro schema* [name]
               +--ro name           string
ADD          +--ro datastore*	ds:datastore-ref {revised-datastores}
               +--ro module* [name revision]
               |  +--ro name                yang:yang-identifier
               |  +--ro revision            union
               |  +--ro schema?             inet:uri
               |  +--ro namespace           inet:uri
               |  +--ro feature*            yang:yang-identifier
               |  +--ro deviation* [name revision]
               |  |  +--ro name        yang:yang-identifier
               |  |  +--ro revision    union
               |  +--ro conformance-type    enumeration
               |  +--ro submodule* [name revision]
               |     +--ro name        yang:yang-identifier
               |     +--ro revision    union
               |     +--ro schema?     inet:uri
               +--ro mount-point* [module name]
                  +--ro module        yang:yang-identifier
                  +--ro name          yang:yang-identifier
                  +--ro config?       boolean
                  +--ro (schema-ref)?
                     +--:(inline)
                     |  +--ro inline?       empty
                     +--:(use-schema)
                        +--ro use-schema* [name]
                           +--ro name
                           |       -> /schema-mounts/schema/name
                           +--ro parent-reference*   yang:xpath1.0

We would expect that the revised-datastores feature would be used
(perhaps required) for any implementation that supports ietf-datastores
and yl-bis.

---

From: Robert Wilton <[email-masked]>
Date: Thu, 22 Feb 2018 17:15:20 +0000

Hi Lou,

I think that this solution is inferior to the model presented in pre-09.

I would prefer that we publish pre09 instead, potentially including the 
-08 model in the appendix if that helps progress the document in a more 
expedient fashion.

Thanks,
Rob

On 22/02/2018 16:18, Lou Berger wrote:
> Chris and I have come up with a proposal on how to provide full NMDA 
> as part the existing schema-mount module.  Our motivation was to 
> enable full NMDA support with *minimal* change to the model and 
> disruption to the LC'ed work.  The key NMDA limitation, with -08, that 
> we are aiming to address is the ability to support different mounted 
> schema in different datastores for non-inline mount points. (See more 
> detailed description below if interested full nuances of limitations 
> of -08)
>
> schema-mount schema is valid/present. This is somewhat similar to 
> YL-bis schema/module-set. Specifically we're proposing (see below for 
> full tree below):
>
>            +--ro schema* [name]
>               +--ro name           string
> This approach has the advantages of supporting different mounted 
> schema in different DSes, working with both NMDA and non-NMDA 
> implementations, supporting all of the extensively discussed features 
> of schema mount (including recursive mounts), and having minor/scoped 
> impact on all dependent work.  The main downside is that it isn't the 
> most optimal/compact solution possible if we were to base this work on 
> issue with the minimal impact on -08 and dependent work -- which is 
> what is appropriate given where we are in the process.
>
> Note: optimization, design preference and perfect alignment with use 
> or YL-bis are not part of our question as we both don't think that is 
> the right question given where we are in the WG process.
>
> As background, my understanding/view is that the -08 version of the 
> both NMDA and non-NMDA supporting implementations, but there are 
> limitations in its NMDA applicability. Used with Yang Library, 
> [rfc7895], only non-NMDA implementations can be supported.  When used 
> with the revised Yang Library defined in 
> [I.D.ietf-netconf-rfc7895bis-],  NMDA implementations  can be 
> supported with certain limitations. Specifically, this document 
> requires use of the now deprecated module-list grouping, and the same 
> schema represented in schema list of the Schema Mount module MUST be 
> used in all datastores.  Inline type mount points, which don't use the 
> schema list,  can support different schema in different data stores 
> not by instantiating the [I.D.ietf-netconf-rfc7895bis-] version of 
> YANG library under the inline mount point.
>
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 23 Feb 2018 10:36:28 +0100 (CET)

Hi,

> I think that this solution is inferior to the model presented in

I agree.  Servers that are NMDA-compliant, or implements YANG Library
bis will have to present schemas in two different structures,
depending on where the schema is used, and clients will have to code
for both.  With the solution in pre-09, there is just one structure.
A single structure also has other benefits (apart from being simpler),
e.g., if we augment it with the meta data that has been discussed
recently, we can augment a single structure.

/martin

> I would prefer that we publish pre09 instead, potentially including
> the -08 model in the appendix if that helps progress the document in a
> more expedient fashion.
> 
> Thanks,
> Rob
> 
>

---

From: Lou Berger <[email-masked]>
Date: Fri, 23 Feb 2018 07:44:53 -0500

Martin/Rob,

     Back when the topic was raised for the first time publicly 
(Yokahama) and discussed in the WG [1] *any* solution would have been 
workable.  At this point > 2 years later, do you really think it is 
reasonable to do a rewrite of the solution ?  Are you really not willing 
to live with a compromise that addresses the issue albeit in way that 
you/some view as suboptimal?

Keep in mind that we had lots of discussions on what is 
optimal/preferred and there are/were different view points on this, 
compromises were made that increased complexity for others and these 
were accepted in interest of progressing *any* deployable solution.

Lou

[1] 
https://datatracker.ietf.org/meeting/interim-2016-netmod-01/session/netmod

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 23 Feb 2018 13:55:09 +0100 (CET)

Hi,

Lou Berger <[email-masked]> wrote:
> reasonable to do a rewrite of the solution ?

I don't agree that this is a rewrite of the solution.  I want to keep
the mountpoint statement.  I want to keep the two mechanisms inline
and use-schema.  The only change we're talking about is alinging the
read-only data that the server makes available with YLbis.  This is
quite trivial.  We have documented this in the pre09 branch, and this
is imo ready to be published.

> Are you really not
> willing to live with a compromise that addresses the issue albeit in
> way that you/some view as suboptimal?
> 

Yes.  I don't want to give up these compromises.  I know that others
want to, and/or explore other solutions.  That's *not* what I'm
proposing.

/martin

---

From: Lou Berger <[email-masked]>
Date: Fri, 23 Feb 2018 08:18:57 -0500

Martin,

On 2/23/2018 7:55 AM, Martin Bjorklund wrote:
> read-only data that the server makes available with YLbis.
The requirement to use YL-bis is enough for me classifying the change as 
a rewrite.  The current draft is usable with both RFC7895 and YL-bis.  
This is a pretty major change, particularly for anyone working on a 
client or server implementation now, or who wants to soon.

>   This is
> quite trivial.
 From *your* perspective.  There are other's that disagree (See Dean's 
and Chris' mail - they don't want *any* changes and are perfectly happy 
with -08).

>   We have documented this in the pre09 branch, and this
It would still need to go through normal working processing which would, 
hopefully, garner some review from some/any of the users or operator who 
contributed to the development of -08.   For example, in PRE09 I see 
some complexities in how mount points with different schema in different 
DS works that seem unnecessary,  also the recursive case is not 
documented - even if I'm wrong and all that is needed is better 
understanding (by me) or clarification (in the doc),  it still would 
need to addressed as part of normal WG processing.

Lou

---

From: Robert Wilton <[email-masked]>
Date: Fri, 23 Feb 2018 14:03:05 +0000

Hi Lou,

I also don't agree that this is a rewrite of the draft.  My view is that 
it is really just an obvious simplification of the YANG module given the 
YLbis work.

For the use-schema version, the -08 version splits the *same* YANG 
library information into two separate places depending on whether it is 
mounted at the root, or below.  The PRE-09 version says that a root 
schema and a mounted schema are really the same thing and should be 
handled in exactly the same way.

On 23/02/2018 13:18, Lou Berger wrote:
> The requirement to use YL-bis is enough for me classifying the change 
> as a rewrite.  The current draft is usable with both RFC7895 and 
> YL-bis.  This is a pretty major change, particularly for anyone 
> working on a client or server implementation now, or who wants to soon.
If semantic versioning, or other stuff (e.g. server/datastore 
capabilities) gets augmented into YLbis then that should just work with 
the pre-09 version, with no further changes.  This will not necessarily 
be the case with the -08 version because it will be using deprecated 
groupings, those deprecated groupings would need to be updated or it 
would force a new version of the SM YANG module.

To support pre NMDA implementations, I see that the solution should be 
the same as all other current YANG model drafts, i.e. if necessary, we 
publish a pre NMDA version of the YANG module in the appendix that works 
with existing implementations.  In this case I would use the model in 
the -08 version, put them both in different namespaces and label them 
clearly.

> and Chris' mail - they don't want *any* changes and are perfectly 
> happy with -08).
>
> It would still need to go through normal working processing which 
> would, hopefully, garner some review from some/any of the users or 
> operator who contributed to the development of -08.   For example, in 
> PRE09 I see some complexities in how mount points with different 
> schema in different DS works that seem unnecessary, also the recursive 
> case is not documented - even if I'm wrong and all that is needed is 
> better understanding (by me) or clarification (in the doc),  it still 
> would need to addressed as part of normal WG processing.
Please can you elaborate, or provide an example of the perceived 
different schema in different datastore complexity.

For the recursive mount case, Juergen has previously posted a useful 
diagram that shows how the -09 model fits with YLbis, that I think would 
be a useful addition.

Perhaps a second WG LC would be sufficient?

>>> way that you/some view as suboptimal?
I think that the YLbis based version is significantly simpler than what 
you/Chris proposed.  If we can't ship a YLbis version now then I prefer 
that the -08 version has no support for NMDA based servers and we 
immediately start SMbis using the YLbis version (i.e. not backwards 
compatible).

I also think that longer term schema mount will end up with a lot more 
usage, which is why I want the -09 model published.

Thanks,
Rob

> .

---

From: Lou Berger <[email-masked]>
Date: Fri, 23 Feb 2018 09:36:50 -0500

Rob,

I think we're going in circles here. We have one camp that wants to replace 
the current module with pre 09 and is unwilling to discuss compromise, and 
another camp that wants 08 published as is and has been waiting for the 
working group and authors to submit aversion to the IESG for publication 
based on the last call that completed in November.

The mail I sent that started this thread was sent with the hope of finding 
a compromise. As you and Martin seem uninterested in discussing a 
compromise, I not sure if it's worth pursuing this thread. If I have 
misread your mails, and you are open to compromise then we should continue 
this thread.

If not and there is no interest in finding a compromise in the working 
group and by the authors, I guess we're back to the plan of publishing 08 
and looking forward to protests.

Lou

---

From: Robert Wilton <[email-masked]>
Date: Fri, 23 Feb 2018 14:52:40 +0000

Hi Lou,

As per my public emails on this WG alias, and also private emails, you 
must know that both Martin, I, and others have been trying (for many 
weeks) to reach a compromise.

I don't think that it is that I am unwilling to compromise, but more 
that I perceive that a different compromise solution is the right one.  
I.e. we publish a single draft that contains the model that you want now 
for pre NMDA solutions, and also a model that we think will work well in 
the post NMDA world that all of the IETF YANG models are moving to.

Thanks,
Rob

On 23/02/2018 14:36, Lou Berger wrote:
> Rob,
>
> I think we're going in circles here. We have one camp that wants to 
> replace the current module with pre 09 and is unwilling to discuss 
> compromise, and another camp that wants 08 published as is and has 
> been waiting for the working group and authors to submit aversion to 
> the IESG for publication based on the last call that completed in 
> November.
>
> The mail I sent that started this thread was sent with the hope of 
> finding a compromise. As you and Martin seem uninterested in 
> discussing a compromise, I not sure if it's worth pursuing this 
> thread. If I have misread your mails, and you are open to compromise 
> then we should continue this thread.
>
> group and by the authors, I guess we're back to the plan of publishing 
> 08 and looking forward to protests.
>
> Lou
>
>
>
> .
>

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 23 Feb 2018 15:55:28 +0100

> I think that this solution is inferior to the model presented in

If the choice is between pre-09 and Lou's new proposal, then I strongly
prefer pre-09.

That said, I must also add that I am still not happy with pre-09: I
believe the "schema-ref" choice is an unnecessary complication - the
"inline" mounts needn't interact at all with the YANG library of the
parent tree.

> -08 model in the appendix if that helps progress the document in a more 

I don't agree with including such an appendix, it would only confuse the
readers.

Lada

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

---

From: Lou Berger <[email-masked]>
Date: Fri, 23 Feb 2018 10:36:17 -0500

Rob,

     My/our proposal doesn't seem to help unblock the current impasse,  
as such I'll drop it and move on.

Thanks,

Lou

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 23 Feb 2018 20:28:14 +0100

> based on the last call that completed in November.

It seems the group in favor of pre 09 is in favor of it because the
solution integrates with YLbis, i.e., _one_ way to represent schema
information.

> The mail I sent that started this thread was sent with the hope of finding a
> compromise. As you and Martin seem uninterested in discussing a compromise,
> I not sure if it's worth pursuing this thread. If I have misread your mails,
> and you are open to compromise then we should continue this thread.

I assume the group in favor of pre 09 finds it difficult to
'compromise' on something that does not provide the benefit of
integrating with YLbis.
 
> If not and there is no interest in finding a compromise in the working group
> and by the authors, I guess we're back to the plan of publishing 08 and
> looking forward to protests.

To investigate the possibility of a compromise, we need to understand
what both groups find unacceptable and where there is room for finding
common grounds.

- For the pre 09 'camp', it seems integration with YLbis is the key
  technical requirement that is driving them.

What is the key technical critical issue for the other camp?

/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: Christian Hopps <[email-masked]>
Date: Sat, 24 Feb 2018 08:54:50 -0500

My position,

It may be the case that there's even a better cleaner solution; however, it's simply too late for major modifications to this work that don't actually address functional failures.  The draft as proposed works for the people who need to get work done.

We have multiple pending RFCs - MISREF on this document. These RFCs would have to be pulled from the RFC EDITOR queue, and reworked to be compliant again, and this very well could lead to discovering issues with your new proposal. Any new issues discovered in either the pending RFCs *or* in the new solution would then need to be worked out and fixed. Please recall that this actually occurred on the first round (i.e., doing the examples led to discovering problems with the drafts), so it's not unreasonable at all to assume this would happen again.

Look this just isn't a simple change your proposing. It involves a large upheaval, killing the pending RFC status on multiple documents that the industry is waiting on. Please see this.

Thanks,
Chris.

---

From: Christian Hopps <[email-masked]>
Date: Sat, 24 Feb 2018 11:37:11 -0500

> What is the key technical critical issue for the other camp?

We have RFCs in the publication queue (i.e., awaiting RFC numbers) to manage VPNs, VMs, etc, that are literally only blocked on this work being published (as written). To change this document in the proposed fashion invalidates the pending RFCs which would then need to be pulled from the publication queue and reworked along with the new proposed changes. The industry is waiting on and needs these RFCs to get work done. I do not think it's reasonable to ask the industry to now wait even longer to go back and rewrite what is already good enough and ready for publication and use.

Thanks,
Chris.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 25 Feb 2018 15:02:03 +0100

> We have RFCs in the publication queue (i.e., awaiting RFC numbers) to manage VPNs, VMs, etc, that are literally only blocked on this work being published (as written). To change this document in th…

If the change to schema mount (i.e., how schema information is
exposed) invalidates the normative parts of documents that define data
models that may exist under a mount point, then I think we got the
coupling between documents wrong.

Anyway, if we can't find a solution that can work for everybody
involved, then we may be left with the only alternative to escalate
this further. My guess is that we will only loose time and we will all
look stupid at the end, hence I was hoping we could avoid this.

/js

---

From: Christian Hopps <[email-masked]>
Date: Sun, 25 Feb 2018 09:36:28 -0500

> coupling between documents wrong.

It invalidates the examples for sure. But normative vs informative isn't the point. Doing the examples last time exposed issues with the design. There's no reason to think that won't occur here. The point is that people are justifying the proposed change by saying it's quick and non-disruptive, and that's simply *not* the case.

We have finished this work, and important stuff that the industry requires is waiting (one wonders how much longer though)

It's time to publish the good work we've done.

> look stupid at the end, hence I was hoping we could avoid this.

If by escalation you mean protests to hold up the work the industry needs during the IESG/IETF LC versus just doing the new work separately?

<sarcasm> Yeah, that'll make us look *really* competent to the industry too. </sarcasm>

One hopes that we don't end up with that nonsense.

Thanks,
Chris.

---

From: Robert Wilton <[email-masked]>
Date: Sun, 25 Feb 2018 18:38:11 +0000

Hi Chris,

I've got no desire or intent to try and slow down the NI and LNE drafts, 
or any that depend on them.  I actually agree that this is critically 
important that IETF gets modules standardized/finished so that everyone 
can use them.

However, ...

YLbis has quite a different structure to YL.  The main part of this 
change was to support NMDA, the other part of this change was to better 
support things like SM, or YANG packages.

I don't think that there is a clean, backwards compatible, way to go 
from the YANG module in SM -08 to one that is going to work well with 
YLbis and other YLbis extensions/augmentations that seem to be coming 
down the line.  Given what we know now, I believe that the correct 
medium/long term structure for the SM YANG module, taking YLbis into 
account, is the one proposed in pre09, because it directly augments the 
YLbis structure, and hence any future augmentations to YLbis should 
automatically extend to SM mounted schema as well.

I think that the likely future technical issues with the -08 module will be:
- supporting NMDA in a clean consistent way
- adding in support for SemVer
- additional capability reporting as an augmentation to YANG library

So, if -08 proceeds as is, then it seems to me like one of three things 
will need to happen:
1) Their will need to be a non backwards compatible update to the SM 
model that is the same/similar to pre09.
2) YLbis and SM diverge, stuff that augments YLbis doesn't work for 
explicitly mounted schema.
3) We accrue technical debt, implementations need to support two YL 
module structures, the one in SM and the one in YLbis, and future 
extensions need to augment both the SM structure and YLbis structure.

I don't like the idea of (2) or (3), but I don't know if others will 
find (1) acceptable.

But I do agree that we are just going round in circles on this:
- Using the pre09 structure is not acceptable to some folks
- Publishing a draft with both -08 and pre09 structure is liked by even 
less folks.

Perhaps publishing -08 is the only option.  My hope is that the WG will 
support somebody subsequently doing solution (1), otherwise it seems 
like a missed opportunity to get this right.

Thanks,
Rob

On 24/02/2018 13:54, Christian Hopps wrote:
> My position,
>
> It may be the case that there's even a better cleaner solution; 
> however, it's simply too late for major modifications to this work 
> that don't actually address functional failures.  The draft as 
> proposed works for the people who need to get work done.
>
> We have multiple pending RFCs - MISREF on this document. These RFCs 
> would have to be pulled from the RFC EDITOR queue, and reworked to be 
> compliant again, and this very well could lead to discovering issues 
> with your new proposal. Any new issues discovered in either the 
> pending RFCs *or* in the new solution would then need to be worked out 
> and fixed. Please recall that this actually occurred on the first 
> round (i.e., doing the examples led to discovering problems with the 
> drafts), so it's not unreasonable at all to assume this would happen 
> again.
>
> Look this just isn't a simple change your proposing. It involves a 
> large upheaval, killing the pending RFC status on multiple documents 
> that the industry is waiting on. Please see this.
>
> Thanks,
> Chris.
>
>

---

From: Christian Hopps <[email-masked]>
Date: Mon, 26 Feb 2018 06:52:10 -0500

Hi Rob,

You do realize that no-one trying to actually deploy and run networks cares about live-discovery of different schema per datastore for the same mount point right? Like 99.999% of the clients know where things are supposed to reside and expect them to be there. At most (although still not common) they may want to know what modules are supported under a mount point. What your talking about is a severe edge case that apparently has achieved extreme importance in a very small group of people's views.

Thanks,
Chris.

Robert Wilton <[email-masked]> writes:

> Hi Chris,
>
> I've got no desire or intent to try and slow down the NI and LNE drafts, or any
> that depend on them. I actually agree that this is critically important that
> IETF gets modules standardized/finished so that everyone can use them.
>
> However, ...
>
> YLbis has quite a different structure to YL. The main part of this change was
> to support NMDA, the other part of this change was to better support things like
> SM, or YANG packages.
>
> I don't think that there is a clean, backwards compatible, way to go from the
> YANG module in SM -08 to one that is going to work well with YLbis and other
> YLbis extensions/augmentations that seem to be coming down the line. Given what
> we know now, I believe that the correct medium/long term structure for the SM
> YANG module, taking YLbis into account, is the one proposed in pre09, because it
> directly augments the YLbis structure, and hence any future augmentations to
> YLbis should automatically extend to SM mounted schema as well.
>
> So, if -08 proceeds as is, then it seems to me like one of three things will
> need to happen:
> 1) Their will need to be a non backwards compatible update to the SM model that
> is the same/similar to pre09.
> 2) YLbis and SM diverge, stuff that augments YLbis doesn't work for explicitly
> mounted schema.
> 3) We accrue technical debt, implementations need to support two YL module
> structures, the one in SM and the one in YLbis, and future extensions need to
> augment both the SM structure and YLbis structure.
>
> I don't like the idea of (2) or (3), but I don't know if others will find (1)
> acceptable.
>
> - Publishing a draft with both -08 and pre09 structure is liked by even less
> folks.
>
> Perhaps publishing -08 is the only option. My hope is that the WG will support
> somebody subsequently doing solution (1), otherwise it seems like a missed
> opportunity to get this right.
>
> Thanks,
> Rob
>
>
>> It may be the case that there's even a better cleaner solution; however, it's
>> simply too late for major modifications to this work that don't actually
>> address functional failures. The draft as proposed works for the people who
>> need to get work done.
>>
>> We have multiple pending RFCs - MISREF on this document. These RFCs would have
>> to be pulled from the RFC EDITOR queue, and reworked to be compliant again,
>> and this very well could lead to discovering issues with your new proposal.
>> Any new issues discovered in either the pending RFCs *or* in the new solution
>> would then need to be worked out and fixed. Please recall that this actually
>> occurred on the first round (i.e., doing the examples led to discovering
>> problems with the drafts), so it's not unreasonable at all to assume this
>> would happen again.
>>
>> Look this just isn't a simple change your proposing. It involves a large
>> upheaval, killing the pending RFC status on multiple documents that the
>> industry is waiting on. Please see this.
>>
>> Thanks,
>> Chris.
>>
>>

---

From: Robert Wilton <[email-masked]>
Date: Mon, 26 Feb 2018 12:35:59 +0000

Hi Chris,

The future issues that I'm predicting is not tied to per datastore 
schema, but because the SM YANG module is tied to a version of YL that 
is being deprecated and replaced by a similar but different structure in 
YLbis.

If all mounted modules are also available at top level modules, and 
hence will be reported in YLbis regardless, then I agree that it 
probably doesn't matter so much.

But if there are YANG modules that are only available at mounted 
locations (and not at the top level) then they would not be listed in 
the top level YANG library and I think that you will hit the issues that 
I describe below.  E.g. you wouldn't be able to retrieve the SemVer 
information for those mounted modules, etc.

Thanks,
Rob

On 26/02/2018 11:52, Christian Hopps wrote:
>
> Hi Rob,
>
> You do realize that no-one trying to actually deploy and run networks 
> cares about live-discovery of different schema per datastore for the 
> same mount point right? Like 99.999% of the clients know where things 
> are supposed to reside and expect them to be there. At most (although 
> still not common) they may want to know what modules are supported 
> under a mount point. What your talking about is a severe edge case 
> that apparently has achieved extreme importance in a very small group 
> of people's views.
>
> Thanks,
> Chris.
>
>> change was
>> from the
>> module
>> find (1)
>>> however, it's
>>> would have
>>> large

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 26 Feb 2018 15:05:09 +0100

Hi Rob,

> YLbis and other YLbis extensions/augmentations that seem to be coming

I don't think this is true - all YANG modules that work with -08 should
work with pre-09.

> explicitly mounted schema.

An acceptable compromise for me would be to publish -08 and accept both
1 and 2 above. The benefits of doing so would be

- LNE/NI work won't be blocked

- some experience may be gained from the implementers that can improve
  the ultimate YLbis-based solution

- there will be more time to reconsider the design and presentation of
  the two concepts (inline and use-schema).

> extensions need to augment both the SM structure and YLbis structure.

If we eventually do the right thing, then SM in the -08 form will be
abandoned along with the old YL.

Lada

---

From: Robert Wilton <[email-masked]>
Date: Mon, 26 Feb 2018 14:16:29 +0000

Hi Lada,

> I don't think this is true - all YANG modules that work with -08 should
Sorry, I think that my point wasn't clear:

I don't think that you can go from the ietf-yang-schema-mount YANG 
module defined in SM -08 to something like the ietf-yang-schema-mount 
YANG module defined in pre09 in a backwards compatible way.  I.e. just 
following the "Updating a Module" in RFC 7950 chapter 11.

In terms of the actual modules that are being mounted, I agree, all 
modules will work in both.

Thanks,
Rob

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 26 Feb 2018 16:03:28 +0100

> following the "Updating a Module" in RFC 7950 chapter 11.

OK, right, but in this case it is necessary to start from a clean slate - old
clients supporting only RFC 7895 cannot work with YLbis, even if the update
rules are followed.

Lada  

> > > > > > > most optimal/compact solution possible if we were to base this
> > > > > > 
> > > > > > work on

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 26 Feb 2018 16:09:21 +0100 (CET)

Hi,

Christian Hopps <[email-masked]> wrote:
> are supposed to reside and expect them to be there.

But then why advertise anything at all?   We can do a *much* simpler
solution by just having the mountpoint extension, and nothing else.
Clients will know what to find anyway.

My experience, which may differ from yours, is that correct knowledge
about the devices' datamodels and revisions is crucial for correct
implementation of automation of network services.  The application
programmer can program the intent for some set of data models, and
then the orchestrator can automatically decide what to do for a given
device depending on which data models it advertises.

/martin

At most (although
> > - less
> > support

---

From: Christian Hopps <[email-masked]>
Date: Mon, 26 Feb 2018 13:51:31 -0500

> Clients will know what to find anyway.

That was the idea Lou and I brought up over 2 *years* ago, yes. :)

But good points were made for something more general and powerful, and we all agreed with those, so..

> device depending on which data models it advertises.

and that's why we have a module list present in the work now ready to publish. It's enough for now. Perfect is killing good enough here.

Thanks,
Chris.

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 27 Feb 2018 08:02:30 +0100

> That was the idea Lou and I brought up over 2 *years* ago, yes. :)

We can and should still do that for the inline case, even after
publishing -08.

> we all agreed with those, so..

This is not true, I have never agreed to mixing up inline and use-schema
cases. Both are useful but they should be separate.

The initial virtual interim decided to use Martin's combined proposal
and most of my subsequent objections were rejected on the basis of that
decision. That's why I hate discussing complicated things in virtual
interims - it it a safe and fast way to reach wrong decisions.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 27 Feb 2018 09:31:16 +0100

> Clients will know what to find anyway.

So it this a possible way out of the current situation? We publish a
trimmed down document that just defines the mount point extension and
we do an update of this document that adds all the details needed to
obtain the schema information?

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 27 Feb 2018 09:38:47 +0100

> obtain the schema information?

I would say so. It would be immediately usable for the inline case.

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 27 Feb 2018 10:15:38 +0100 (CET)

> obtain the schema information?

Not optimal, but I can accept this as a way to move forward.

/martin

---

From: Kent Watsen <[email-masked]>
Date: Tue, 27 Feb 2018 14:03:07 +0000

/js

+1

This was something I suggested a while back.  Though I didn’t detail this specific proposal, rather something along the lines of removing unnecessary parts, in order to reduce the debt carried forward as much as possible.

Kent   // contributor

---

From: Christian Hopps <[email-masked]>
Date: Wed, 28 Feb 2018 13:28:48 -0500

> I would say so. It would be immediately usable for the inline case.

This still requires that we pull the routing NI work from the RFC ED queue, change normative text (the document specifically states that use-schema MUST be present, although it does mention that that may be relaxed in the future) as well as the examples listing the schema/modules, this is going to require at least another run through WGLC. It's slightly less obnoxious than the original proposal as its simply removing stuff and losing functionality vs. changing functionality.

Thanks,
Chris.