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

[Martin Bjorklund <[e-mail]>]

Robert Wilton <[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.

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