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

From: Vladimir Vassilev <[email-masked]>
Date: Wed, 15 Nov 2017 10:41:57 +0100

On 11/15/2017 01:06 AM, Robert Wilton wrote:
>
>
> On 14/11/2017 23:41, Vladimir Vassilev wrote:
>>
>>
>> On 11/13/2017 04:27 PM, Robert Wilton wrote:
>>>
>>> Hi Vladimir,
>>>
>>>
>>> On 12/11/2017 10:39, Vladimir Vassilev wrote:
>>>>
>>>>
>>>>
>>>> On 11/11/2017 08:07 PM, Andy Bierman wrote:
>>>>>
>>>>>
>>>>> On Fri, Nov 10, 2017 at 3:06 AM, Robert Wilton <[email-masked] 
>>>>> <mailto:[email-masked]>> wrote:
>>>>>
>>>>>     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.
>>>>>
>>>>>
>>>>>
>>>>> 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.
>>>
>>> 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.
>> 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?
> 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
I still do not see an argument against supporting  NMDA modules with 
yang-library:1.0 in the case when and only when there are no deviations 
and the implemented module sets are exactly identical for all datastores.
>
>
>>
>> Vladimir
>>
>>>
>>> Thanks,
>>> Rob
>>>
>>>>>  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.
>>>>>
>>>>>     These rules seem more restrictive that what a server using split
>>>>>     config state trees (IETF style, or OpenConfig style) can achieve
>>>>>     using deviations today.
>>>>>
>>>>>
>>>>>
>>>>> Lots of rules to enforce actually makes the code harder, not easier.
>>>>>
>>>>>     Thanks,
>>>>>     Rob
>>>>>
>>>>>
>>>>>
>>>>> Andy
>>>>>
>>>>>
>>>>>
>>>>>     On 09/11/2017 19:33, Andy Bierman wrote:
>>>>>>     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] <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:
>>>>>>
>>>>>>         (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
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Netconf mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/netconf
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Netconf mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/netconf
>>>
>>
>> .
>>
>

---

From: Robert Wilton <[email-masked]>
Date: Wed, 15 Nov 2017 11:42:56 +0100

On 15/11/2017 10:41, Vladimir Vassilev wrote:
>>> implemented will not need yang-library:1.1 implementation which 
>>> takes one obstacle out of the way to rolling NMDA module 
>>> implementations.
>>>
>> 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 
> yang-library:1.0 in the case when and only when there are no 
> deviations and the implemented module sets are exactly identical for 
> all datastores.
OK, so when a client reads the YANG modules on the old YANG library 
path, then how do they distinguish between:
(i) the information is accurate and correct
(ii) the information isn't precise because there are per datastore 
differences.

Thanks,
Rob

>>>>>> (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"
>>>>>>
>>>>>>

---

From: Vladimir Vassilev <[email-masked]>
Date: Wed, 15 Nov 2017 13:10:41 +0100

On 11/15/2017 11:42 AM, Robert Wilton wrote:
>>>>>>> On Fri, Nov 10, 2017 at 3:06 AM, Robert Wilton 
>>>>>>> I am not convinced that moving to a datastore-centric 
>>>>>>> conformance model instead of server-centric
>>>>>>> is a good idea.
>>>>>> +1
>>>>>> 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.
>>>>>
>>> the new structure can be entirely accurate.  I.e. it can report 
>>> which modules are available in which datastores.
>>>
>>> YANG library could be inaccurate.  I.e. I think that it has to 
>>> report all modules and deviations as being reported in all datastores.
>>>
>>> that we are proposing below are intended to be easier for a client 
>>> to determine this, e.g. by checking whether any of the 
It is clear that datastores with non-identical models can not be 
supported with yang-library:1.0. However for the many usecases that do 
not require the complexity of having different datastore models 
(variation of the set of modules and the relevant deviations e.g. more 
complex datastore centric conformance model) one can implement NMDA with 
yang-library:1.0.

My initial proposal was a change to draft-ietf-netconf-nmda-netconf-01 
sec. 2.4. 'YANG Library Capability' to allow that usecase:

OLD:
Support for NMDA requires the server to implement at least revision 
201X-XX-XX of the "ietf-yang-library"
...
NEW:
Support for NMDA with datastores with non-identical models requires the 
server to implement at least revision 201X-XX-XX of the "ietf-yang-library"
...

With that there is no room left for (i) is the only option.

Vladimir
>>>>>>> This new complexity is non-trivial to implement, so it may not 
>>>>>>> be widely supported.
>>>>>>>

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 15 Nov 2017 13:20:11 +0100 (CET)

Vladimir Vassilev <[email-masked]> wrote:

[...]

> complex datastore centric conformance model) one can implement NMDA
> with yang-library:1.0.
> 
> Support for NMDA with datastores with non-identical models requires
> the server to implement at least revision 201X-XX-XX of the
> "ietf-yang-library"

But that would imply that we keep two versions of ietf-yang-library
around, and "current".

Also note that the new proposed version is very similar in structure
to the old yang library.  And if the server implements "identicial
models", then the "not-implemented-in" will be empty, and so the
contents of yang-library 1.1 is more or less the same as yang-library
1.0.

/martin

---

From: Vladimir Vassilev <[email-masked]>
Date: Wed, 15 Nov 2017 14:44:04 +0100

> contents of yang-library 1.1 is more or less the same as yang-library
I aggree with what you say. My point is that the upgrade to 
yang-library:1.1 can come later then the upgrade to NMDA ietf-interfaces 
<get-data> etc. I will implement yang-library:1.1 as soon as I find a 
single usecase that justifies the work needed. At the moment I only have 
motivation to implement <get-data> and migrate to the NMDA modules and 
the only issue with that plan is the text in 
draft-ietf-netconf-nmda-netconf-01 sec. 2.4. 'YANG Library Capability'.

Following my gut feeling I would rather wait to see if yang-library:1.2 
is not coming up before I am done with the process of migrating to NMDA 
with identical datastore models. A reasonable concern taking into 
account yang-library:1.0 is about to be obsoleted so soon after the 
publication of rfc7895 because of a feature (introduction of 
datastore-centric conformance model) that has no value for me at the 
moment unlike the feature (unification of configuration and state trees) 
introduced with NMDA.

That said there might be a counter argument that the confusion of 
allowing NMDA implementations with both yang-library:1.0 and 
yang-library:1.1 is worse then forcing all NMDA applications to 
implement only yang-library:1.1. If this is so that should be stated 
clearly.

Vladimir

---

From: Vladimir Vassilev <[email-masked]>
Date: Wed, 15 Nov 2017 18:21:27 +0100

Hello,

I have a proposal based on <get-data> that provides an elegant solution 
to consider as a 3rd option.  It is based on keeping exactly the same 
model as in RFC 7895 and using <get-data> RPC to retrieve datastore 
specific yang-library instance data in a similar way one would use 
<get-data> to retrieve the datastore contents. In addition a top level 
config=false container e.g. /datastores with list of supported 
datastores that does not need to be part of the yang-library module:

module: ietf-datastores
+--ro datastores

Vladimir

On 11/09/2017 05:51 PM, Robert Wilton 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:
>
> (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.
>
> *(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).
>
>     +--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".
>
>     +--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
>
>
>            |     +--ro module*   -> ../../../modules/module/id
>            +--ro datastores
>            |             -> ../../../module-sets/module-set/id
>            +--ro checksum       string
>

---

From: Robert Wilton <[email-masked]>
Date: Thu, 16 Nov 2017 01:29:25 +0800

I don't think that this is really a good idea.  You would end up 
returning server metadata in addition to the configuration.

I still think that the YANG library proposal is the best solution.

Thanks,
Rob

On 16/11/2017 01:21, Vladimir Vassilev wrote:
> Hello,
>
> I have a proposal based on <get-data> that provides an elegant 
> solution to consider as a 3rd option.  It is based on keeping exactly 
> the same model as in RFC 7895 and using <get-data> RPC to retrieve 
> datastore specific yang-library instance data in a similar way one 
> would use <get-data> to retrieve the datastore contents. In addition a 
> top level config=false container e.g. /datastores with list of 
> supported datastores that does not need to be part of the yang-library 
> module:
>
> module: ietf-datastores
> +--ro datastores
>> 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).
>> (v) Datastores are now just a list of supported datastores (that 
>> could potentially be extended with further per datastore properties 
>> in future).
>>
>> augmentation (i.e. version (2)), or is it better that schema-mount 
>> has its own separate subtree?
>>

---

From: Andy Bierman <[email-masked]>
Date: Wed, 15 Nov 2017 10:29:33 -0800

Hi,

The per-datastore feature aspect of NMDA is a new and significant change to
YANG.

YANG does not define feature conformance at this granularity.
I strongly object to this change to YANG conformance.
A server can only advertise a YANG feature if it implemented on the entire
server.

This extra complexity is not present on the openconfig solution or
requirements.
Comparing any datastore to <operational> is much more complex (any may not
be possible)
if the features are different for a given module.

I do not see how <operational> can be true superset of the conventional
datastores
if the features are different.

Andy

On Wed, Nov 15, 2017 at 9:29 AM, Robert Wilton <[email-masked]> wrote:

> I don't think that this is really a good idea.  You would end up returning
> server metadata in addition to the configuration.
>
> I have a proposal based on <get-data> that provides an elegant solution to
> consider as a 3rd option.  It is based on keeping exactly the same model as
> in RFC 7895 and using <get-data> RPC to retrieve datastore specific
> yang-library instance data in a similar way one would use <get-data> to
> retrieve the datastore contents. In addition a top level config=false
> container e.g. /datastores with list of supported datastores that does not
> need to be part of the yang-library module:
>
> module: ietf-datastores
> +--ro datastores
> 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.
> (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.
> (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).
> *(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.*
>
> 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.
>
> schema list, and the primary schema for the device would always be given
> the name "primary".
>
> augmentation (i.e. version (2)), or is it better that schema-mount has its
> own separate subtree?
>
> Netconf mailing [email-masked]://www.ietf.org/mailman/listinfo/netconf
>
>
>
>
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>
>

---

From: Robert Wilton <[email-masked]>
Date: Thu, 16 Nov 2017 08:53:18 +0800

Hi Andy,

On 16/11/2017 02:29, Andy Bierman wrote:
> Hi,
>
> The per-datastore feature aspect of NMDA is a new and significant 
> change to YANG.
>
> A server can only advertise a YANG feature if it implemented on the 
> entire server.
>
In terms of comparison, it definitely is:
- you can have different features for the config and state trees (e.g. 
"router-id" feature in RFC 8022).
- sometimes the conventions are not followed completely consistently, 
e.g. different types, or semantics between config and state.
- sometimes the structures differ between config and state.

So, the problem comparing between config and state is not easier in 
either the IETF split tree or OpenConfig solutions.

> Comparing any datastore to <operational> is much more complex (any may 
> not be possible)
You can always compare (except deviations in operational).  If a feature 
is enabled on any configuration datastore then it must also be enabled 
on operational.

E.g.  take "router-id" feature from RFC8022bis (that was also defined in 
RFC8022).

This feature can be enabled:
(i) everywhere (i.e. <conventional> + <i2rs-ephemeral> + <operational>), or
(ii) <conventional> + <operational>, or
(iii) <i2rs-ephemral> + <operational>, or
(iv) <operational> only, or
(v) or in none of them.

Hence, <operational> always contains a superset of the nodes.

>
> I do not see how <operational> can be true superset of the 
> conventional datastores

Because of the statement above.

Thanks,
Rob

>
>
> Andy
>
>
> On Wed, Nov 15, 2017 at 9:29 AM, Robert Wilton <[email-masked] 
>>     solution to consider as a 3rd option.  It is based on keeping
>>     exactly the same model as in RFC 7895 and using <get-data> RPC to
>>     retrieve datastore specific yang-library instance data in a
>>     similar way one would use <get-data> to retrieve the datastore
>>     contents. In addition a top level config=false container e.g.
>>     /datastores with list of supported datastores that does not need
>>     to be part of the yang-library module:
>>
>>     module: ietf-datastores
>>     +--ro datastores
>>>     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.
>>>
>>>     structure.*
>>>     (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.
>>>     (with a "not-implemented-in" leaflist of datastores that a
>>>     module is not implemented in).
>>>     default (with a "not-implemented-in" leaflist of datastores that
>>>     a feature is not implemented in).
>>>     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
>>>
>>>
>>>     [email-masked] <mailto:[email-masked]>
>>>     <https://www.ietf.org/mailman/listinfo/netconf>
>>
>
>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/netmod>
>
>

---

From: Andy Bierman <[email-masked]>
Date: Wed, 15 Nov 2017 18:42:20 -0800

On Wed, Nov 15, 2017 at 4:53 PM, Robert Wilton <[email-masked]> wrote:

> The per-datastore feature aspect of NMDA is a new and significant change
> to YANG.
>
> - sometimes the conventions are not followed completely consistently, e.g.
> different types, or semantics between config and state.
> So, the problem comparing between config and state is not easier in either
> the IETF split tree or OpenConfig solutions.
>
> is enabled on any configuration datastore then it must also be enabled on
> operational.
>
>
This is not apparent from the text. The draft-02 library is very out of
date at this point.

I only care about restricting the conventional datastores, <intended> and
<operational>.
It will be a massive client rewrite if the client cannot compare <intended>
to <operational>
with 1 schema tree.

If the updated draft reflects the feature-in-operational requirement above
then
I have no objections to the proposed YANG library functionality.

I am still concerned about per-datastore deviations.
IMO, the server MUST implement the same deviations in these special
datastores.
If that cannot be done, the operational node will not be present. Another
leaf node
(like admin-state/oper-state) needs to be used instead.

If the server does implement per-datastore deviations,
clients may not work (if they use the conventional datastore schema tree
for <operational>).
The same thing happens if the client ignores plain-old-deviations now,
so this is not a big deal.

> (iv) <operational> only, or

I still think the WG needs to define YANG conformance for datastores,
The question "what datastores does server implementation X support for
module foo?" is covered.
The question "what datastores MUST, SHOULD, MAY a compliant server
implementation
support for module foo?" is totally ignored.

Andy

>> to consider as a 3rd option.  It is based on keeping exactly the same model
>> as in RFC 7895 and using <get-data> RPC to retrieve datastore specific

---

From: Robert Wilton <[email-masked]>
Date: Thu, 16 Nov 2017 14:56:35 +0800

Hi Andy,

On 16/11/2017 10:42, Andy Bierman wrote:
>
>
> On Wed, Nov 15, 2017 at 4:53 PM, Robert Wilton <[email-masked] 
>>     A server can only advertise a YANG feature if it implemented on
>>     the entire server.
>>
>>     This extra complexity is not present on the openconfig solution
>>     or requirements.
>     - you can have different features for the config and state trees
>     (e.g. "router-id" feature in RFC 8022).
>     - sometimes the conventions are not followed completely
>     consistently, e.g. different types, or semantics between config
>     and state.
>     So, the problem comparing between config and state is not easier
>     in either the IETF split tree or OpenConfig solutions.
>
>>     Comparing any datastore to <operational> is much more complex
>>     (any may not be possible)
>     You can always compare (except deviations in operational).  If a
>     feature is enabled on any configuration datastore then it must
>     also be enabled on operational.
>
>
> This is not apparent from the text.

I agree that this can be better explained, either in YANG library, 
and/or in the datastores architecture.  This is implied by the datastore 
draft today, but there is no harm to make it a bit more explicit.

> The draft-02 library is very out of date at this point.

Yes, sorry.  The -02 is out of date with the latest proposal which was 
discussed/developed after the cutoff date.   Functionality wise they are 
intended to be capable of expressing the same things, but the proposal 
in this original thread is intended to be simpler.

>
> I only care about restricting the conventional datastores, <intended> 
> and <operational>.
> It will be a massive client rewrite if the client cannot compare 
> <intended> to <operational>
> with 1 schema tree.

<intended> also counts as a conventional datastore so the list of 
modules, features, deviations MUST be the same as for <running>, 
<startup>, and <candidate>.

But yes, I entirely agree that it must be possible to compare from 
<intended> to <operational> in an easy way.  Arguably that is one of the 
key aspects of this work.

>
> If the updated draft reflects the feature-in-operational requirement 
> above then

OK, we will ensure that this is clearly documented.

> IMO, the server MUST implement the same deviations in these special 

For a normal server YANG deviation "e.g. changing types, or value space, 
etc" then the same deviations MUST be applied to ALL datastores.

> If that cannot be done, the operational node will not be present. 
> Another leaf node

Yes, entirely agree.

The only type of per datastore deviation is to remove a node. Further, 
if that deviation is applied to one of the conventional datastores then 
it must apply to all of the conventional datastores.

> clients may not work (if they use the conventional datastore schema 
> tree for <operational>).

I think that I agree.

>
>
>
>
>     E.g.  take "router-id" feature from RFC8022bis (that was also
>     defined in RFC8022).
>

The RESTCONF NMDA draft states:

    An NMDA-compliant RESTCONF server MUST support the operational state
    datastore.  Such a server identifies that it supports NMDA both by
    implementing the {+restconf}/ds/ietf-datastores:operational resource,
    and by implementing at least revision 201X-XX-XX of the
    "ietf-yang-library" module, as specified in
    [I-D.nmdsdt-netconf-rfc7895bis].

The NETCONF NMDA protocol draft should have a similar statement.

Do you think that this conformance statement is insufficient?

Or is your concern about whether modules are expected to be implemented?

Thanks,
Rob

>>         I don't think that this is really a good idea.  You would end
>>         up returning server metadata in addition to the configuration.
>>
>>>         I have a proposal based on <get-data> that provides an
>>>         elegant solution to consider as a 3rd option.  It is based
>>>         on keeping exactly the same model as in RFC 7895 and using
>>>         <get-data> RPC to retrieve datastore specific yang-library
>>>         instance data in a similar way one would use <get-data> to
>>>         retrieve the datastore contents. In addition a top level
>>>         config=false container e.g. /datastores with list of
>>>         supported datastores that does not need to be part of the
>>>         yang-library module:
>>>
>>>         module: ietf-datastores
>>>         +--ro datastores

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 16 Nov 2017 12:38:57 +0100 (CET)

Robert Wilton <[email-masked]> wrote:
> - (e.g. "router-id" feature in RFC 8022).
> - e.g. different types, or semantics between config and state.
> feature is enabled on any configuration datastore then it must also be
> enabled on operational.

But this is not really correct, since features can be negated,
e.g. you might have:

  feature bar;

  leaf foo {
    if-feature "not bar";
    ...
  }

In this case, it is fine to have "bar" in config but not oper.

I think that saying that the schema for operational MUST be a superset
of the schema for conventional handles this case.

/martin

> 
> E.g.  take "router-id" feature from RFC8022bis (that was also defined
> in RFC8022).
>