Subject: [Netconf] Alternative YANG library structure for 7895bis

From: Robert Wilton <[email-masked]>
Date: Thu, 9 Nov 2017 16:51:16 +0000

Hi,

Given some of the feedback related to the complexity of the YANG library 
bis structure, we have come up with two other possible structures for 
the YANG library data:

(1) A simplified structure to make YANG library meet the NMDA 
requirements, but that is closer to the existing YANG library structure, 
and arguably simpler.
(2) An enhanced version of the structure (1) above, that is also 
extended to allow the structure to be reused for schema-mount via an 
augmentation.

For reference, at the end of this email, I have also included the tree 
diagram of the existing YANG library, and the current YANG library bis 
draft (draft-ietf-netconf-rfc7895bis-02) version.

Considering the two new YANG library structures:

------------------------

*(1) A simplified structure to make YANG library meet the NMDA 
requirements, but that is closer to the existing YANG library structure.*

The main changes are:
(i) Split "implemented modules" and "import-only-modules" into two 
separate lists, making the most important list (i.e. implemented 
modules) keyed by module name only and hence easier to reference.
(ii) Assume modules are implemented in all datastores by default (with a 
"not-implemented-in" leaflist of datastores that a module is not 
implemented in).
(iii) Assume that features are implemented in all datastores by default 
(with a "not-implemented-in" leaflist of datastores that a feature is 
not implemented in).
(iv) Deleted module-sets.
(v) Datastores are now just a list of supported datastores (that could 
potentially be extended with further per datastore properties in future).

Manually generated tree output for proposed YANG library:

module: ietf-yang-library
  +--ro yang-library
     +--ro modules
     |  +--ro module* [name]
     |  |  +--ro name           yang:yang-identifier
     |  |  +--ro revision?      revision-identifier
     |  |  +--ro schema?        inet:uri
     |  |  +--ro namespace      inet:uri
     |  |  +--ro submodule* [name]
     |  |  |  +--ro name        yang:yang-identifier
     |  |  |  +--ro revision?   yang:yang-identifier
     |  |  |  +--ro schema?     inet:uri
     |  |  +--ro not-implemented-in*
     |  |  |              -> /yang-library/datastore/name
     |  |  +--ro feature* [name]
     |  |  |  +--ro name        yang:yang-identifier
     |  |  |  +--ro not-implemented-in*
     |  |  |              -> /yang-library/datastore/name
     |  |  +--ro deviation*
     |  |                 -> ../name
     |  |
     |  +--ro import-only-module* [name revision]
     |     +--ro name                yang:yang-identifier
     |     +--ro revision            union
     |     +--ro schema?             inet:uri
     |     +--ro namespace           inet:uri
     |     +--ro submodule* [name]
     |        +--ro name        yang:yang-identifier
     |        +--ro revision    yang:revision-identifier
     |        +--ro schema?     inet:uri
     +--ro datastore* [name] // Allows future per datastore properties.
     |  +--ro name          identityref
     +--ro checksum       string

------------------------------

*(2) An enhanced version of the structure (1) above, that is extended to 
allow the structure to be reused for schema-mount via an augmentation.*

This is similar to the structure above, except that the "the set of 
modules" is contained in a list of named schema (e.g. similar to the 
schema mount draft), allowing this structure to be re-used for schema mount.

Schema mount would be expected to augment yang-library to add in the 
additional schema mount information.  In the tree diagram, I have shown 
the schema-mount mount-point augmentation, but not including namespaces yet.

Every server would be required to provide at least one schema in the 
schema list, and the primary schema for the device would always be given 
the name "primary".

module: ietf-yang-library
  +--ro yang-library
     +--ro schema* [name]
     |  +--ro name           string
     |  +--ro checksum       string
     |  +--ro module* [name]
     |  |  +--ro name           yang:yang-identifier
     |  |  +--ro revision?      yang:revision-identifier
     |  |  +--ro schema?        inet:uri
     |  |  +--ro namespace      inet:uri
     |  |  +--ro submodule* [name]
     |  |  |  +--ro name        yang:yang-identifier
     |  |  |  +--ro revision?   yang:yang-identifier
     |  |  |  +--ro schema?     inet:uri
     |  |  +--ro not-implemented-in*
     |  |  |              -> /yang-library/datastore/name
     |  |  +--ro feature* [name]
     |  |  |  +--ro name        yang:yang-identifier
     |  |  |  +--ro not-implemented-in*
     |  |  |              -> /yang-library/datastore/name
     |  |  +--ro deviation*
     |  |  |              -> ../name
     |  |  +- schema-mount:mount-point* [label]
     |  |     +--ro label         yang:yang-identifier
     |  |     +--ro config?       boolean
     |  |     +--ro (schema-ref)
     |  |        +--:(inline)
     |  |        |  +--ro inline?       empty
     |  |        +--:(use-schema)
     |  |           +--ro use-schema* [name]
     |  |              +--ro name
     |  |              |       -> /yang-library/schema/name
     |  |              +--ro parent-reference* yang:xpath1.0
     |  |
     |  +--ro import-only-module* [name revision]
     |     +--ro name                yang:yang-identifier
     |     +--ro revision            union
     |     +--ro schema?             inet:uri
     |     +--ro namespace           inet:uri
     |     +--ro submodule* [name]
     |        +--ro name        yang:yang-identifier
     |        +--ro revision    yang:revision-identifier
     |        +--ro schema?     inet:uri
     +--ro datastore* [name] // Allows future per datastore properties.
     |  +--ro name          identityref
     +--ro checksum       string

Please can you provide comments on these structures, in particular:

Is this version better (i.e. simpler) that the version currently in 
draft-ietf-netconf-rfc7895bis-02 (below)?

Should we try and make the structure extensible for schema-mount via 
augmentation (i.e. version (2)), or is it better that schema-mount has 
its own separate subtree?

For reference only I have included the existing YANG library and YANG 
library bis draft tree diagrams.

Thanks,
Rob

-----------------------------

*** FOR REFERENCE ONLY ***

(3)  The current YANG library structure in YANG library bis 
(draft-ietf-netconf-rfc7895bis-02)

    module: ietf-yang-library
        +--ro yang-library
           +--ro modules
           |  +--ro module* [id]
           |     +--ro id                  string
           |     +--ro name                yang:yang-identifier
           |     +--ro revision?           revision-identifier
           |     +--ro schema?             inet:uri
           |     +--ro namespace           inet:uri
           |     +--ro feature*            yang:yang-identifier
           |     +--ro deviation* [module]
           |     |  +--ro module    -> ../../id
           |     +--ro conformance-type    enumeration
           |     +--ro submodule* [name]
           |        +--ro name        yang:yang-identifier
           |        +--ro revision?   revision-identifier
           |        +--ro schema?     inet:uri
           +--ro module-sets
           |  +--ro module-set* [id]
           |     +--ro id        string
           |     +--ro module*   -> ../../../modules/module/id
           +--ro datastores
           |  +--ro datastore* [name]
           |     +--ro name          identityref
           |     +--ro module-set
           |             -> ../../../module-sets/module-set/id
           +--ro checksum       string

-----------------------------

*** FOR REFERENCE ONLY ***

(4)  The current YANG library structure (RFC 7895)

       +--ro modules-state
          +--ro module-set-id    string
          +--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

---

From: Andy Bierman <[email-masked]>
Date: Thu, 9 Nov 2017 11:33:51 -0800

Hi,

The new structure still has the same problems for the client as before.
It is a major change in the architecture to have different schema trees per
datastore instead of per-server.
The server is allowed to have different features and deviations for the
same objects.
The client is completely on its own trying to compare <operational> to
anything
if the schema trees are different

  container foo {
    leaf bar {
       if-feature X;
       type string;
    }
    leaf baz {
       if-feature "not X";
       type string;
    }
 }

How does the client compare <running> to <operational> if the features do
not match?
If the server deviates the leaf (e.g. change type string to int32) how does
the client
compare the values?

This new complexity would be mandatory for the client to support in some
proprietary
manner since the NMDA standard ignores these problems.

NMDA was supposed to be simpler because the client could compare intended
and applied values using the same object path. openconfig required a data
model change and a trivial name-mapping. In reality, NMDA
is far more disruptive to existing implementations.

Andy

On Thu, Nov 9, 2017 at 8:51 AM, Robert Wilton <[email-masked]> wrote:

> bis structure, we have come up with two other possible structures for the
> YANG library data:
>
> (2) An enhanced version of the structure (1) above, that is also extended
> to allow the structure to be reused for schema-mount via an augmentation.
>
> separate lists, making the most important list (i.e. implemented modules)
> keyed by module name only and hence easier to reference.
> (with a "not-implemented-in" leaflist of datastores that a feature is not
> implemented in).
> modules" is contained in a list of named schema (e.g. similar to the schema
> mount draft), allowing this structure to be re-used for schema mount.
>
> additional schema mount information.  In the tree diagram, I have shown the
> schema-mount mount-point augmentation, but not including namespaces yet.
>
> augmentation (i.e. version (2)), or is it better that schema-mount has its
> own separate subtree?
>

---

From: Robert Wilton <[email-masked]>
Date: Fri, 10 Nov 2017 11:06:39 +0000

Hi Andy,

The NMDA datastore draft (draft-ietf-netmod-revised-datastores-06) 
mandates two constraints that must apply:

(1) All conventional datastores must have exactly the same schema.  
Hence differences in deviations or features are allowed between these 
datastores. (sec 5.1, first paragraph)

(2) The schema for operational must be a superset of all configuration 
datatstores, but that data nodes may be omitted (sec 5.3, third paragraph).

This implies that only the following differences between datastores are 
allowed:
  (i) a feature can be disabled in conventional (and/or dynamic 
configuration datastores), but enabled in operational (e.g. for 
configurable router-id).

  (ii) deviations apply in all datastores, except that
   a) a deviation can remove nodes in the conventional datastores (if 
they were not configurable, like the feature example)
   b) a deviation can remove nodes in a dynamic datastore (e.g. like I2RS)
   c) a deviation can remove nodes from operational only if a server is 
unable to accurately report them.

(iii) modules exist in all datastores, except:
   a) a module can be omitted from conventional datastores (e.g. if the 
module is not configurable)
   b) a module can be omitted from a dynamic datastore (e.g. like I2RS)
   c) a module can be omitted from operational only if a server is 
unable to accurately report the data nodes within the module.

Changing the type of a node between datastores, or changing its 
properties is not allowed.  The only difference allowed between data 
nodes in different datastores is the nodes existence.

These rules seem more restrictive that what a server using split config 
state trees (IETF style, or OpenConfig style) can achieve using 
deviations today.

Thanks,
Rob

On 09/11/2017 19:33, Andy Bierman wrote:
> It is a major change in the architecture to have different schema 
> trees per datastore instead of per-server.
> The server is allowed to have different features and deviations for 
> the same objects.
> How does the client compare <running> to <operational> if the features 
> do not match?
> If the server deviates the leaf (e.g. change type string to int32) how 
> does the client
> compare the values?
>
> This new complexity would be mandatory for the client to support in 
> some proprietary
> On Thu, Nov 9, 2017 at 8:51 AM, Robert Wilton <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi,
>
>     Given some of the feedback related to the complexity of the YANG
>     library bis structure, we have come up with two other possible
>     structures for the YANG library data:
>
>     requirements, but that is closer to the existing YANG library
>     structure, and arguably simpler.
>     extended to allow the structure to be reused for schema-mount via
>     an augmentation.
>
>     For reference, at the end of this email, I have also included the
>     tree diagram of the existing YANG library, and the current YANG
>     library bis draft (draft-ietf-netconf-rfc7895bis-02) version.
>
>     (ii) Assume modules are implemented in all datastores by default
>     (with a "not-implemented-in" leaflist of datastores that a module
>     is not implemented in).
>     (iii) Assume that features are implemented in all datastores by
>     default (with a "not-implemented-in" leaflist of datastores that a
>     feature is not implemented in).
>     (v) Datastores are now just a list of supported datastores (that
>     could potentially be extended with further per datastore
>     properties in future).
>
>     *(2) An enhanced version of the structure (1) above, that is
>     extended to allow the structure to be reused for schema-mount via
>     an augmentation.*
>
>     This is similar to the structure above, except that the "the set
>     of modules" is contained in a list of named schema (e.g. similar
>     to the schema mount draft), allowing this structure to be re-used
>     for schema mount.
>
>     Schema mount would be expected to augment yang-library to add in
>     the additional schema mount information.  In the tree diagram, I
>     have shown the schema-mount mount-point augmentation, but not
>     including namespaces yet.
>
>     Every server would be required to provide at least one schema in
>     the schema list, and the primary schema for the device would
>     always be given the name "primary".
>
>     Is this version better (i.e. simpler) that the version currently
>     in draft-ietf-netconf-rfc7895bis-02 (below)?
>
>     Should we try and make the structure extensible for schema-mount
>     via augmentation (i.e. version (2)), or is it better that
>     schema-mount has its own separate subtree?
>
>     For reference only I have included the existing YANG library and
>     YANG library bis draft tree diagrams.
>
>     Thanks,
>     Rob
>
>

---

From: Andy Bierman <[email-masked]>
Date: Sat, 11 Nov 2017 11:07:40 -0800

On Fri, Nov 10, 2017 at 3:06 AM, Robert Wilton <[email-masked]> wrote:

> (1) All conventional datastores must have exactly the same schema.  Hence
> differences in deviations or features are allowed between these datastores.
> (sec 5.1, first paragraph)
>
>   a) a deviation can remove nodes in the conventional datastores (if they
> were not configurable, like the feature example)
>   c) a module can be omitted from operational only if a server is unable
> to accurately report the data nodes within the module.
>
>
>
I am not convinced that moving to a datastore-centric conformance model
instead of server-centric
is a good idea.  I get it that it is supposed to allow the server to
accurately reflect its implementation,
but it actually says that servers MAY implement whatever partial subset of
a module they want,
and a client MUST deal with the mess.

IMO, YANG says that features and deviations are server-wide, not
per-datastore.
This new complexity is non-trivial to implement, so it may not be widely
supported.

The WG seems confused about the difference between a conformance model and
capabilities reporting.
(ii)(c) and (iii)(c) is about reporting, not conformance.  There is still
no way to express
trivial use-cases in the conformance model such as "this module is intended
for the I2RS ephemeral datastore only"

Changing the type of a node between datastores, or changing its properties
> is not allowed.  The only difference allowed between data nodes in
> different datastores is the nodes existence.
>
> state trees (IETF style, or OpenConfig style) can achieve using deviations
> today.
>
>

Lots of rules to enforce actually makes the code harder, not easier.

Andy

> It is a major change in the architecture to have different schema trees
> per datastore instead of per-server.

---

From: Vladimir Vassilev <[email-masked]>
Date: Sun, 12 Nov 2017 03:39:14 +0100

On 11/11/2017 08:07 PM, Andy Bierman wrote:
>
>
> On Fri, Nov 10, 2017 at 3:06 AM, Robert Wilton <[email-masked] 
>     (1) All conventional datastores must have exactly the same
>     schema.  Hence differences in deviations or features are allowed
>     between these datastores. (sec 5.1, first paragraph)
>
>     (2) The schema for operational must be a superset of all
>     configuration datatstores, but that data nodes may be omitted (sec
>     5.3, third paragraph).
>
>
>     This implies that only the following differences between
>     datastores are allowed:
>       a) a deviation can remove nodes in the conventional datastores
>     (if they were not configurable, like the feature example)
>       c) a deviation can remove nodes from operational only if a
>     server is unable to accurately report them.
>
>       a) a module can be omitted from conventional datastores (e.g. if
>     the module is not configurable)
> I am not convinced that moving to a datastore-centric conformance 
> model instead of server-centric
> is a good idea.
+1
IMO yang-library:1.1 can and should be optional. As a first step NMDA 
modules and the minimal protocol support <get-data> etc. can be 
implemented without yang-library 1.0 to 1.1 transition (read 
server-centric to datastore-centric conformance model transition). 
draft-ietf-netconf-nmda-netconf-01.txt requires migration to 
yang-library:1.1. I do not see good argument to support this limitation 
and there are usecases that can benefit from NMDA with uniform datastore 
model design.
>  I get it that it is supposed to allow the server to accurately 
> reflect its implementation,
> but it actually says that servers MAY implement whatever partial 
> subset of a module they want,
> This new complexity is non-trivial to implement, so it may not be 
> widely supported.
>
> The WG seems confused about the difference between a conformance model 
> and capabilities reporting.
> (ii)(c) and (iii)(c) is about reporting, not conformance.  There is 
> still no way to express
> trivial use-cases in the conformance model such as "this module is 
> intended for the I2RS ephemeral datastore only"
>
>
>     properties is not allowed.  The only difference allowed between
>     data nodes in different datastores is the nodes existence.
>
>     These rules seem more restrictive that what a server using split
>     config state trees (IETF style, or OpenConfig style) can achieve
>     using deviations today.
>
>
>
>>     The server is allowed to have different features and deviations
>>     for the same objects.
>>     The client is completely on its own trying to compare
>>     <operational> to anything
>>     How does the client compare <running> to <operational> if the
>>     features do not match?
>>     If the server deviates the leaf (e.g. change type string to
>>     int32) how does the client
>>     compare the values?
>>
>>     This new complexity would be mandatory for the client to support
>>     in some proprietary
>>         Given some of the feedback related to the complexity of the
>>         YANG library bis structure, we have come up with two other
>>         possible structures for the YANG library data:
>>
>>         (2) An enhanced version of the structure (1) above, that is
>>         also extended to allow the structure to be reused for
>>         schema-mount via an augmentation.
>>
>>         For reference, at the end of this email, I have also included
>>         the tree diagram of the existing YANG library, and the
>>         current YANG library bis draft
>>         (draft-ietf-netconf-rfc7895bis-02) version.
>>
>>         *(1) A simplified structure to make YANG library meet the
>>         NMDA requirements, but that is closer to the existing YANG
>>         library structure.*
>>
>>         The main changes are:
>>         (i) Split "implemented modules" and "import-only-modules"
>>         into two separate lists, making the most important list (i.e.
>>         implemented modules) keyed by module name only and hence
>>         easier to reference.
>>         (ii) Assume modules are implemented in all datastores by
>>         default (with a "not-implemented-in" leaflist of datastores
>>         that a module is not implemented in).
>>         (iii) Assume that features are implemented in all datastores
>>         by default (with a "not-implemented-in" leaflist of
>>         datastores that a feature is not implemented in).
>>         (v) Datastores are now just a list of supported datastores
>>         (that could potentially be extended with further per
>>         datastore properties in future).
>>
>>         extended to allow the structure to be reused for schema-mount
>>         via an augmentation.*
>>
>>         This is similar to the structure above, except that the "the
>>         set of modules" is contained in a list of named schema (e.g.
>>         similar to the schema mount draft), allowing this structure
>>         to be re-used for schema mount.
>>
>>         Schema mount would be expected to augment yang-library to add
>>         in the additional schema mount information.  In the tree
>>         diagram, I have shown the schema-mount mount-point
>>         augmentation, but not including namespaces yet.
>>
>>         Every server would be required to provide at least one schema
>>         in the schema list, and the primary schema for the device
>>         would always be given the name "primary".
>>
>>         Is this version better (i.e. simpler) that the version
>>         currently in draft-ietf-netconf-rfc7895bis-02 (below)?
>>
>>         Should we try and make the structure extensible for
>>         schema-mount via augmentation (i.e. version (2)), or is it
>>         better that schema-mount has its own separate subtree?
>>
>>         For reference only I have included the existing YANG library
>>         and YANG library bis draft tree diagrams.
>>
>>         Thanks,
>>         Rob
>>
>>
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

---

From: Robert Wilton <[email-masked]>
Date: Mon, 13 Nov 2017 23:27:39 +0800

Hi Vladimir,

On 12/11/2017 10:39, Vladimir Vassilev wrote:
>>     The NMDA datastore draft
>>     (draft-ietf-netmod-revised-datastores-06) mandates two
>>     constraints that must apply:
>>
>>     configuration datatstores, but that data nodes may be omitted
>>     (sec 5.3, third paragraph).
>>
>>
>>       a) a module can be omitted from conventional datastores (e.g.
>>     if the module is not configurable)
> yang-library:1.1. I do not see good argument to support this 
> limitation and there are usecases that can benefit from NMDA with 
> uniform datastore model design.

YANG library bis is the mechanism to indicate which datastores are 
available to the client.  E.g. a NMDA compatible client would attempt to 
read YANG library bis on the new path using the <get-data> RPC to 
determine whether NMDA is supported, and what datastores are supported.

The existing module-state path in YANG library is preserved, but marked 
as deprecated, so the intention is that it can be made backwards 
compatible to clients.

Thanks,
Rob

>> The WG seems confused about the difference between a conformance 
>> model and capabilities reporting.
>>>     It is a major change in the architecture to have different
>>>     schema trees per datastore instead of per-server.
>>>         (1) A simplified structure to make YANG library meet the
>>>         library structure, and arguably simpler.
>>>         For reference, at the end of this email, I have also
>>>         included the tree diagram of the existing YANG library, and
>>>         the current YANG library bis draft
>>>         into two separate lists, making the most important list
>>>         (i.e. implemented modules) keyed by module name only and
>>>         hence easier to reference.
>>>         extended to allow the structure to be reused for
>>>         schema-mount via an augmentation.*
>>>
>>>         Schema mount would be expected to augment yang-library to
>>>         add in the additional schema mount information. In the tree
>>>         Every server would be required to provide at least one
>>>         schema in the schema list, and the primary schema for the
>>>         device would always be given the name "primary".
>>>

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 13 Nov 2017 16:41:21 +0100 (CET)

Robert Wilton <[email-masked]> wrote:
> This implies that only the following differences between datastores
> are allowed:

Maybe this should be clarified in the text.

> config state trees (IETF style, or OpenConfig style) can achieve using
> deviations today.

Exactly, which in fact makes it easier to do comparisions between
intended and applied.

/martin

---

From: Vladimir Vassilev <[email-masked]>
Date: Tue, 14 Nov 2017 16:41:21 +0100

On 11/13/2017 04:27 PM, Robert Wilton wrote:
>>>       c) a module can be omitted from operational only if a server
>>>     is unable to accurately report the data nodes within the module.
>>>
>>>
>>>
> available to the client.  E.g. a NMDA compatible client would attempt 
> to read YANG library bis on the new path using the <get-data> RPC to 
> The existing module-state path in YANG library is preserved, but 
> marked as deprecated, so the intention is that it can be made 
> backwards compatible to clients.
I agree draft-ietf-netconf-nmda-netconf-01 sec. 2.4. 'YANG Library 
Capability'  states exactly that. IMO this text can be changed and allow 
the case described above (<get-data> implementation with NMDA modules 
implemented as indicated by yang-library:1.0 uniform model applying to 
all datastores. For cases where the datastores do not have common model 
yang-library:1.1 should still be mandatory). In other words if 
yang-library:1.0 shows implemented ietf-netconf-datastores <get-data> 
and NMDA modules listed as implemented will not need yang-library:1.1 
implementation which takes one obstacle out of the way to rolling NMDA 
module implementations.

Is there an argument making the proposed change unreasonable?

Vladimir

>>>>     This new complexity would be mandatory for the client to
>>>>     support in some proprietary
>>>>     On Thu, Nov 9, 2017 at 8:51 AM, Robert Wilton
>>>>     <[email-masked] <mailto:[email-masked]>> wrote:
>>>>
>>>>         Hi,
>>>>
>>>>         (iii) Assume that features are implemented in all
>>>>         datastores by default (with a "not-implemented-in" leaflist
>>>>         of datastores that a feature is not implemented in).
>>>>         *(2) An enhanced version of the structure (1) above, that
>>>>         is extended to allow the structure to be reused for
>>>>         This is similar to the structure above, except that the
>>>>         "the set of modules" is contained in a list of named schema
>>>>         (e.g. similar to the schema mount draft), allowing this
>>>>         structure to be re-used for schema mount.
>>>>
>>>>         add in the additional schema mount information.  In the
>>>>         tree diagram, I have shown the schema-mount mount-point
>>>>         For reference only I have included the existing YANG
>>>>         library and YANG library bis draft tree diagrams.
>>>>
>>>>         Thanks,
>>>>         Rob
>>>>
>>>>

---

From: Robert Wilton <[email-masked]>
Date: Wed, 15 Nov 2017 08:06:28 +0800

On 14/11/2017 23:41, Vladimir Vassilev wrote:
>>> IMO yang-library:1.1 can and should be optional. As a first step 
>>> NMDA modules and the minimal protocol support <get-data> etc. can be 
> Capability'  states exactly that. IMO this text can be changed and 
> allow the case described above (<get-data> implementation with NMDA 
> modules implemented as indicated by yang-library:1.0 uniform model 
> applying to all datastores. For cases where the datastores do not have 
> common model yang-library:1.1 should still be mandatory). In other 
> words if yang-library:1.0 shows implemented ietf-netconf-datastores 
> <get-data> and NMDA modules listed as implemented will not need 
> yang-library:1.1 implementation which takes one obstacle out of the 
> way to rolling NMDA module implementations.
>
Yes, I think so.

In an NMDA implementation, the YANG library information reported in the 
new structure can be entirely accurate.  I.e. it can report which 
modules are available in which datastores.

Of course, it is not possible to represent this in the old YANG library, 
so the information that a NMDA server provides via the old YANG library 
could be inaccurate.  I.e. I think that it has to report all modules and 
deviations as being reported in all datastores.

Hence the only way that a client would be able to know that it is 
talking to an NMDA server with modules not implemented in some 
datastores, or with deviations in some datastores would be for it to 
query the new YANG library path.  The new YANG library structures that 
we are proposing below are intended to be easier for a client to 
determine this, e.g. by checking whether any of the "not-implemented-in" 
leaf-lists are populated.

So the aim for keeping the old YANG library path is to inter-operate 
with old clients that don't know about NMDA, and hence would not be 
expected to use the <edit-data> or <get-data> RPCs.

Thanks,
Rob

> .

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 15 Nov 2017 23:13:10 +0800

Hi Rob,

I am sorry for a late reply but I needed to re-check my earlier
proposal first. Essentially, it is quite similar to your second
schema-mount-friendly version, except that I also proposed to explicitly
specify the schema for each datastore. If several datastores share the
same schema, then it is possible to define it as one of the named schema
entries, and just refer to its name in each datastore description.

But I like your proposal, too. I think it would be a huge improvement,
and I am prepared to help with the draft.

Thanks, Lada

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