This message ends this WGLC.
While there seems to be general support, there doesn’t appear to be support for
the provided use cases (i.e., data object tags for metric and operation type),
and significant concern that a node-tag can change the definition of anything
the schema.
Authors, please
On Wed, Sep 2, 2020 at 3:55 AM Juergen Schoenwaelder <
j.schoenwael...@jacobs-university.de> wrote:
> I continue to have a problem with changing YANG import semantics using
> extension statements. Versioning people should understand that this is
> an NBC change and hence they should request that
Hi,
My second email on imports ...
RFC 7950 supports two variants of import: The default choice is import any
revision of a module, but the revision-date substatement may be used to
restrict the import to a single specific revision. The "import specific
revision" has been found to be less
rfc6991bis adds some useful types but is it ok to start using them in I-Ds that
are currently at the last call stage by using import by revision? I appreciate
that any such I-D will have to wait on 6991bis to advance but will the validity
checking of the module be able to find the revision
I continue to have a problem with changing YANG import semantics using
extension statements. Versioning people should understand that this is
an NBC change and hence they should request that the YANG version
number is changed.
/js
On Wed, Sep 02, 2020 at 10:51:38AM +, Rob Wilton (rwilton)
Hi,
During the NETMOD 108 meeting I had made a comment that imports using
revision-or-derived are not done using a semantic version number, but instead
are done by revision label, which limits how they behave and what they are
allowed to do. Some participants were concerned that this might be
