Robert Wilton <rwil...@cisco.com> 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.
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). > > 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 > > if the features are different. > > Because of the statement above. > > Thanks, > Rob > > > > > > > Andy > > > > > > On Wed, Nov 15, 2017 at 9:29 AM, Robert Wilton <rwil...@cisco.com > > <mailto:rwil...@cisco.com>> 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 > >>> netc...@ietf.org <mailto:netc...@ietf.org> > >>> https://www.ietf.org/mailman/listinfo/netconf > >>> <https://www.ietf.org/mailman/listinfo/netconf> > >> > > > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org <mailto:netmod@ietf.org> > > https://www.ietf.org/mailman/listinfo/netmod > > <https://www.ietf.org/mailman/listinfo/netmod> > > > > > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod