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

[Robert Wilton <[e-mail]>]

Hi Andy,


On 16/11/2017 10:42, Andy Bierman wrote:
>
>
> On Wed, Nov 15, 2017 at 4:53 PM, Robert Wilton <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     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.
>>
>>>         |  |  +--ro feature* [name]
>>>         |  |  |  +--ro name yang:yang-identifier
>>>         |  |  |  +--ro not-implemented-in*
>>>         |  |  |              -> /yang-library/datastore/name
>>>
>>
>>     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.
>     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)
>>     if the features are different for a given module.
>     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
> I have no objections to the proposed YANG library functionality.

OK, we will ensure that this is clearly documented.


>
> I am still concerned about per-datastore deviations.
> IMO, the server MUST implement the same deviations in these special 
> datastores.

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
> (like admin-state/oper-state) needs to be used instead.

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.


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

I think that I agree.


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

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


>
>
>     Hence, <operational> always contains a superset of the nodes.
>
>>
>>     I do not see how <operational> can be true superset of the
>>     conventional datastores
>>     if the features are different.
>
>     Because of the statement above.
>
>     Thanks,
>     Rob
>
>
>
>
> Andy
>
>>
>>
>>     Andy
>>
>>
>>     On Wed, Nov 15, 2017 at 9:29 AM, Robert Wilton <[e-mail]
>>     <mailto:[e-mail]>> 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 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
>>>         |  +--ro datastore* [name]
>>>         |     +--ro name          identityref
>>>
>>>         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.
>>>>
>>>>         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
>>>>         [e-mail] <mailto:[e-mail]>
>>>>         https://www.ietf.org/mailman/listinfo/netconf
>>>>         <https://www.ietf.org/mailman/listinfo/netconf>
>>>
>>
>>
>>         _______________________________________________
>>         netmod mailing list
>>         [e-mail] <mailto:[e-mail]>
>>         https://www.ietf.org/mailman/listinfo/netmod
>>         <https://www.ietf.org/mailman/listinfo/netmod>
>>
>>
>
>