Robert Wilton <[email protected]> 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 <[email protected]
> > <mailto:[email protected]>> 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
> >>> [email protected] <mailto:[email protected]>
> >>> https://www.ietf.org/mailman/listinfo/netconf
> >>> <https://www.ietf.org/mailman/listinfo/netconf>
> >>
> >
> >
> > _______________________________________________
> > netmod mailing list
> > [email protected] <mailto:[email protected]>
> > https://www.ietf.org/mailman/listinfo/netmod
> > <https://www.ietf.org/mailman/listinfo/netmod>
> >
> >
>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
