Re: [netmod] reference statement examples in draft-ietf-netmod-rfc6087bis-18

[Kent Watsen]

Juergen writes:
> I think it was common practice to write
>
>   reference "RFC 6991: Common YANG Data Types";
>
> instead of just
>
>   reference "RFC 6991";

Agreed, I always do.


> that is to include the RFC title (this can be especially useful with
> longer lists of references and less commonly known RFC numbers). It
> seems that draft-ietf-netmod-rfc6087bis-18 kind of suggests to only
> use the RFC number (section 3.2 and section 4.7).

If you're suggesting modifying the examples in rfc6087bis, as a 
contributor, I support.

As shepherd, it would be good to hear more support for this change
before formalizing a request.


Kent




___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] ACL draft issues found during shepherd writeup

[Kent Watsen]

Hi Mahesh,

Please search for  below (6 instances)

Thanks,
Kent // shepherd


On 2/17/18, 8:26 PM, "Mahesh Jethanandani" 
> wrote:

Kent,

Thanks for a detailed review. See inline.


On Feb 13, 2018, at 2:30 PM, Kent Watsen 
> wrote:

[sorry, wrong WG, moving netconf to BCC!]


ACL Authors,

Below are some issues I found while looking at doing the Shepherd
write-up today.  Please take a look.

Also, with regards to the request for those having Last Call comments
to please verify that their comments were addressed, I only saw one
response from Kristian, but should we be expecting respeonses from
others too, perhaps Einar or Elliot?

Eliot can confirm if he feels his issues have been addressed.




1 IDNITS

 - some issues found by idnits
 - using 
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_tools_idnits_=DwICAg=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=7Bx3hgofSFxvNRV7Xz7FuaJcKKfzEB0sBJzN_KOCtSg=_5f-lxCoJW2TidcrjW_KbDkdPhfxLoL67kn1A2okgs0=
 - without selecting "verbose output"


1.1

 ** There are 5 instances of too long lines in the document, the longest one
being 5 characters in excess of 72.

Fixed.




 This "**" is being flagged as an "error".
 Idnits label, not mine.  Please fix.


1.2

 == There are 7 instances of lines with non-RFC6890-compliant IPv4 addresses
in the document.  If these are example addresses, they should be changed.

 This is just a warning, but given that there are seven occurrences, it
 might be a good idea to fix.  Please see Section 3, point #6 in this
 document for details: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_id-2Dinfo_checklist=DwICAg=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=7Bx3hgofSFxvNRV7Xz7FuaJcKKfzEB0sBJzN_KOCtSg=AYo8ZHPY4SAHMqcy1qV9yr7BjoxGy_C9zcJ_ZbwXBT4=.

Fixed.




1.3

 ** The document seems to lack a both a reference to RFC 2119 and the
recommended RFC 2119 boilerplate, even if it appears to use RFC 2119
keywords.

RFC 2119 keyword, line 797: '...s-list. A device MAY restrict the leng...'


 There needs to be a section that looks like RFC 8174, paragraph 11:

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY",
and "OPTIONAL" in this document are to be interpreted as
described in BCP 14 [RFC2119] [RFC8174] when, and only when, they
appear in all capitals, as shown here.

Added.




1.4.

 -- The document date (February 2, 2018) is 11 days in the past.  Is this
intentional?

 This is fine, ignore it.

1.5

 ** Obsolete normative reference: RFC 2460

 This needs to be fixed.

Updated the reference to RFC 8200.



1.6

 ** Downref: Normative reference to an Historic RFC: RFC 3540

 H, another HISTORIC document, but this time not due to an IESG
 action.  The question is how important this reference is, is this
 "ns" bit (ECN-nonce concealment protection) commonly used in the
 industry?

I do not know enough to know it is not used. If the consensus is that we do not 
use it, I can drop it from the model.

 As shepherd, I would like the normative reference to a historic RFC 
removed from this draft.   My recommendation is to remove it.  As chair, if 
anyone wants to make a case for keeping the "ns" bit, *now* is
your time to say something.


1.7

 == Outdated reference: A later version (-06) exists of
draft-ietf-netmod-yang-tree-diagrams-04

 Please update to -06

This might be because the draft was last published when -04 was around. I do 
not reference any particular version. My reference is to
. The tool pulls 
in the latest when it generates the draft.


1.8

 -- Obsolete informational reference (is this intentional?): RFC 5101
(Obsoleted by RFC 7011)

 Please update to RFC 7011

Done.





2  YANG VALIDATION

2.1 Normative Modules

 All of the following passed:

   pyang --ietf ietf-access-control-list\@2018-02-02.yang
   pyang --ietf ietf-packet-fields\@2018-02-02.yang
   pyang --ietf ietf-ethertypes\@2018-02-02.yang

   yanglint -s ietf-access-control-list\@2018-02-02.yang
   yanglint -s ietf-packet-fields\@2018-02-02.yang
   yanglint -s ietf-ethertypes\@2018-02-02.yang

2.2 Example Module

 Example module passed `yanglint -s`, but not `pyang --lint`:

   yanglint -s example-newco-acl.yang
   pyang --lint example-newco-acl.yang

   example-newco-acl.yang:78: error: keyword "description" not in
   canonical order, expected "type", (See RFC 6020, Section 12)

   example-newco-acl.yang:79: error: keyword "type" not in
   canonical order, (See RFC 6020, Section 12)

   example-newco-acl.yang:82: error: keyword "default" not in
   canonical order, (See RFC 6020, Section 12)

 Please fix.

Fixed.




2.3 XML Examples from Section 4.3

 yanglint didn't find any issues:

   yanglint 

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

[Juergen Schoenwaelder]

On Fri, Feb 23, 2018 at 09:36:50AM -0500, 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.

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 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] AD review of draft-ietf-netmod-syslog-model-20

[Mahesh Jethanandani]

Kent,

> On Feb 23, 2018, at 8:02 AM, Kent Watsen  wrote:
> 
> Hi Clyde,
> 
> Looking at your diff, I see that you aligned the Usage Example text and 
> artwork by making the artwork use the IP address from the text, but you 
> should've instead used the hostname in both locations.  Please see section 
> 3.6 here: https://www.ietf.org/standards/ids/checklist 
> .
> 
> Also, I see that you moved the Editorial Note to Section 1.4 (along with a 
> typo in the title, ooops).  This is fine, I guess, though I was thinking 
> instead about something like a top-level "RFC Editor Considerations" near the 
> end [hmmm, a budding BCP? ;)].  Actually, I wish you had explained that the 
> text was not in the Abstract, but in a "" element, and it was just a 
> rendering issue.  It's actually common to use the  element for this 
> purpose (sorry for not recognizing it before). Please also either fix the 
> typo or, better, move the section back to the  element.

I had recommended the move of the note from abstract section to the end of the 
Introduction section. Abstracts cannot have cross-references in them, which the 
note had. And that was one of the OPS-DIR comments too.

> 
> Kent // shepherd
> 
> 
> = original message =
> 
> Kent, Tom, Yaron, and Ron,
> 
> A new version of the draft-ietf-netmod-syslog-model has been published that 
> addresses your concerns.
> 
> Thanks,
> 
> 
> 
> Clyde
> 
> 
> 
> On 2/20/18, 9:06 AM, "netmod on behalf of Kent Watsen" 
>  on behalf of 
> kwat...@juniper.net > wrote:
> 
> 
> 
> 
> 
> 
> 
> 
> 
>> Kent
> 
>> 
> 
>> You illustrate beautifully the problem I would like a solution to.
> 
>> 
> 
>> The current thinking AFAICT is that tree-diagrams
> 
>> should be an Informative Reference.
> 
>> 
> 
>> Therefore, the RFC Editor will not hold publication until an RFC number
> 
>> is assigned.
> 
>> 
> 
>> Therefore, a note asking the I-D reference to be updated to reflect the
> 
>> assigned RFC number is null - the RFC can be published with the
> 
>> reference as an i-d and not as an RFC which is what I expect the RFC
> 
>> Editor to do.
> 
>> 
> 
>> QED
> 
> 
> 
> 
> 
>Except I know that this draft will be stuck in MISREF state and 
> tree-diagrams
> 
>will in fact be assigned an RFC number by the time this draft is published.
> 
> 
> 
>K.
> 
> 
> 
> 
> 
>> Note that this is not the case of a Normative i-d reference being buried
> 
>> in the YANG module and not being.noticed by the RFC Editor; that problem
> 
>> I am content with.
> 
>> 
> 
>> 
> 
>> Tom Petch
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>> 
> 
>> Please also address these issues when posting -21 to address Benoit's
> 
>issues.  Please post -21 ASAP as Benoit has already placed this draft on
> 
>the IESG telechat in a couple weeks.
> 
>> 
> 
>> Thanks,
> 
>> Kent // shepherd
> 
>> 
> 
>> 
> 
>> On 2/14/18, 8:18 AM, "netmod on behalf of Benoit Claise"
> 
> on behalf of
> 
>bcla...@cisco.com> wrote:
> 
>> 
> 
>> Dear all,
> 
>> 
> 
>> - the draft is NMDA compliant, right? It should be mentioned.
> 
>> Ex: draft-ietf-netmod-rfc7223bis-03, in the abstract and intro
> 
>> 
> 
>>   The YANG model in this document conforms to the Network Management
> 
>> 
> 
>>   Datastore Architecture defined in
> 
>I-D.ietf-netmod-revised-datastores.
> 
>> 
> 
>> 
> 
>> - As mentioned in the writeup, [I-D.ietf-netmod-yang-tree-diagrams]
> 
>should be an informative reference, not normative.
> 
>> 
> 
>> - Editorial:
> 
>> OLD:
> 
>> This draft addresses the common leafs
> 
>> NEW:
> 
>> This document addresses the common leafs
> 
>> 
> 
>> Please publish a new version asap.
> 
>> In the mean time, I'm sending this draft to IETF LC.
> 
>> 
> 
>> Regards, Benoit
> 
>> 
> 
>> 
> 
>> 
> 
> 
> 
> 
> 
>
> 
>
> 
> 
> 
> 
> 
>> ___
> 
>> netmod mailing list
> 
>> netmod@ietf.org
> 
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod=DwICaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=cJ7MVnQVc1hgxpVF7oYiVn6Rbm-Qf2dDyrfYhL-s9io=u0Hn9GkO-B0jUGm1MnIQ4x4AgIZNXHBIaZhTPmt3dC8=
> 
>> 
> 
> 
> 
> 
> 
> 
> 
>___
> 
>netmod mailing list
> 
>netmod@ietf.org
> 
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod=DwIGaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=vELsmeOQEHNm4fcyJJKG7EpwwzMBGc-MHvHhSPWRzro=jSGwP16XlM6ntMKUF3bkCAwRfRtRwATdly2BlUtx2RA=
>  
> 

[netmod] feedback draft-rtgyangdt-netmod-module-tags -> draft-ietf-netmod-module-tags

[joel jaeggli]

introduction / abstract should capture the problem module tags are
attempting to solve succinctly

Robert Wilton's criticism of the approach is well taken; the use of tags
as regular configuration (his approach) vs the treatment of tags as
exceptions (how we understand them as proposed). and seems like a ket
architectural consideration in advancing this draft.

joel



signature.asc
Description: OpenPGP digital signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Adoption Poll Completed: draft-rtgyangdt-netmod-module-tags-02

[joel jaeggli]

This completes the 2 week poll on making
draft-rtgyangdt-netmod-module-tags-02 a working group document.

https://tools.ietf.org/html/draft-rtgyangdt-netmod-module-tags-02

This document was most recently discussed at IETF 100.

Response has been generally favorable and enthusiasic with some interest
in signficant changes. We are adopting the document as a working group item.

The authors should submit an updated draft probably with the title
draft-ietf-netmod-module-tags-02.

thanks
joel




signature.asc
Description: OpenPGP digital signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] AD review of draft-ietf-netmod-syslog-model-20

[Kent Watsen]

Hi Clyde,

Looking at your diff, I see that you aligned the Usage Example text and artwork 
by making the artwork use the IP address from the text, but you should've 
instead used the hostname in both locations.  Please see section 3.6 here: 
https://www.ietf.org/standards/ids/checklist.

Also, I see that you moved the Editorial Note to Section 1.4 (along with a typo 
in the title, ooops).  This is fine, I guess, though I was thinking instead 
about something like a top-level "RFC Editor Considerations" near the end 
[hmmm, a budding BCP? ;)].  Actually, I wish you had explained that the text 
was not in the Abstract, but in a "" element, and it was just a rendering 
issue.  It's actually common to use the  element for this purpose (sorry 
for not recognizing it before).  Please also either fix the typo or, better, 
move the section back to the  element.

Kent // shepherd


= original message =

Kent, Tom, Yaron, and Ron,

A new version of the draft-ietf-netmod-syslog-model has been published that 
addresses your concerns.

Thanks,



Clyde



On 2/20/18, 9:06 AM, "netmod on behalf of Kent Watsen"  wrote:









> Kent

> 

> You illustrate beautifully the problem I would like a solution to.

>

> The current thinking AFAICT is that tree-diagrams

> should be an Informative Reference.

>

> Therefore, the RFC Editor will not hold publication until an RFC number

> is assigned.

> 

> Therefore, a note asking the I-D reference to be updated to reflect the

> assigned RFC number is null - the RFC can be published with the

> reference as an i-d and not as an RFC which is what I expect the RFC

> Editor to do.

> 

> QED





Except I know that this draft will be stuck in MISREF state and 
tree-diagrams

will in fact be assigned an RFC number by the time this draft is published.



K.





> Note that this is not the case of a Normative i-d reference being buried

> in the YANG module and not being.noticed by the RFC Editor; that problem

> I am content with.

>

>

>Tom Petch

















>

> Please also address these issues when posting -21 to address Benoit's

issues.  Please post -21 ASAP as Benoit has already placed this draft on

the IESG telechat in a couple weeks.

>

> Thanks,

> Kent // shepherd

>

>

> On 2/14/18, 8:18 AM, "netmod on behalf of Benoit Claise"

 on behalf of

bcla...@cisco.com> wrote:

>

> Dear all,

>

> - the draft is NMDA compliant, right? It should be mentioned.

> Ex: draft-ietf-netmod-rfc7223bis-03, in the abstract and intro

>

>The YANG model in this document conforms to the Network Management

>

>Datastore Architecture defined in

I-D.ietf-netmod-revised-datastores.

>

>

> - As mentioned in the writeup, [I-D.ietf-netmod-yang-tree-diagrams]

should be an informative reference, not normative.

>

> - Editorial:

> OLD:

> This draft addresses the common leafs

> NEW:

> This document addresses the common leafs

>

> Please publish a new version asap.

> In the mean time, I'm sending this draft to IETF LC.

>

> Regards, Benoit

>

>

>













> ___

> netmod mailing list

> netmod@ietf.org

> 
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod=DwICaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=cJ7MVnQVc1hgxpVF7oYiVn6Rbm-Qf2dDyrfYhL-s9io=u0Hn9GkO-B0jUGm1MnIQ4x4AgIZNXHBIaZhTPmt3dC8=

>







___

netmod mailing list

netmod@ietf.org


https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod=DwIGaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=vELsmeOQEHNm4fcyJJKG7EpwwzMBGc-MHvHhSPWRzro=jSGwP16XlM6ntMKUF3bkCAwRfRtRwATdly2BlUtx2RA=







___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Lou Berger]

Rob,

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


Thanks,

Lou

On 2/23/2018 9:52 AM, Robert Wilton wrote:

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.

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



.





___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Secdir last call review of draft-ietf-netmod-syslog-model-21

[Kent Watsen]

>  Security Comments
>  
>  * I think almost all writable data nodes here are sensitive, because 
a network
>  attacker's first move is to block any logging on the host, and many 
of the data
>  nodes here can be used for this purpose.
> 
> [clw1] I will reword the security section to include all writeable nodes 
as sensitive.
> 
>  * Re: readable data nodes, I'm not
>  sure which are sensitive, and the document should give an example or 
two rather
>  than just say "some". Otherwise the security advice is not 
actionable. One
>  example: "remote" sections leak information about other hosts in the 
network.
> 
> [clw1] This text was lifted from another model. I will review the 
readable nodes and update.
> 
>  * Write operations... can have a negative effect on network 
operations. - I would
>  add "and on network security", because logs are often used to detect 
security
>  breaches.
> 
> [clw1] I will add this phrase.
> 

The fact that the syslog data nodes are write-sensitive can be made explicit in
the model by making the whole configuration tree nacm:default-deny-write, and
making read-sensitive subtrees nacm:default-deny-all.

Thanks,
Gary Wu


 Agreed.  Usually my modules have the NACM annotations and then, in the
Security Considerations section, I'm sure to point them out.


K.




___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Ladislav Lhotka]

Robert Wilton  writes:

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

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.

>
> 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.

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

Lada

>
> Thanks,
> Rob
>
>
> On 22/02/2018 16:18, Lou Berger wrote:
>> 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 

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

[Robert Wilton]

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.


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



.



___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Lou Berger]

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



___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Robert Wilton]

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:

Martin,


On 2/23/2018 7:55 AM, Martin Bjorklund wrote:

Hi,

Lou Berger  wrote:

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 ?

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.
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.





  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
is imo ready to be published.
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?



Lou




Are you really not
willing to live with a compromise that addresses the issue albeit in
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




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.

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




Lou

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



On 2/23/2018 4:36 AM, Martin Bjorklund wrote:

Hi,

Robert Wilton  wrote:

Hi Lou,

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

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 

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

[Lou Berger]

Martin,


On 2/23/2018 7:55 AM, Martin Bjorklund wrote:

Hi,

Lou Berger  wrote:

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 ?

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.
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
is imo ready to be published.
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




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.

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




Lou

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

On 2/23/2018 4:36 AM, Martin Bjorklund wrote:

Hi,

Robert Wilton  wrote:

Hi Lou,

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

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


On 22/02/2018 16:18, Lou Berger wrote:

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 

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

[Martin Bjorklund]

Hi,

Lou Berger  wrote:
> 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 ?

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?
> 
> 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.

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



> 
> Lou
> 
> [1]
> https://datatracker.ietf.org/meeting/interim-2016-netmod-01/session/netmod
> 
> On 2/23/2018 4:36 AM, Martin Bjorklund wrote:
> > Hi,
> >
> > Robert Wilton  wrote:
> >> Hi Lou,
> >>
> >> I think that this solution is inferior to the model presented in
> >> pre-09.
> > 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
> >>
> >>
> >> On 22/02/2018 16:18, Lou Berger wrote:
> >>> 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 

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

[Lou Berger]

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


On 2/23/2018 4:36 AM, Martin Bjorklund wrote:

Hi,

Robert Wilton  wrote:

Hi Lou,

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

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


On 22/02/2018 16:18, Lou Berger wrote:

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
 

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

[Martin Bjorklund]

Hi,

Robert Wilton  wrote:
> Hi Lou,
> 
> I think that this solution is inferior to the model presented in
> pre-09.

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
> 
> 
> On 22/02/2018 16:18, Lou Berger wrote:
> > 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