On 2019. 02. 07. 13:10, Robert Wilton
wrote:
Hi Balazs,
Regarding identifying the instance data using a YANG package.
If the YANG packages work is liked by the WG and progresses,
then it seems plausible that a YANG package could become a
better way of identifying the set of modules rather than using
YANG library for a couple of reasons:
1) It will allow modules to be identified via semantic version
rather than just revision date. This will likely be more
meaningful to readers.
BALAZS: The nice thing about using yang-library is that when the
semver work augment the library with the module-version it will be
available for instance-data for free.
2) It allows for a much more concise definition. Rather than
having to try and infer what schema a particular set of YANG
modules related to from the list of modules, it can instead
refer to a single package definition and version number.
BALAZS: Using packages would be more, concise however in some cases
you might not want to declare a package. E.g. we use a modular
architecture where one design group might be responsible for only
one YANG module (YAM). They need to deliver some instance-data
related to that YAM, but they don't want to declare a package that
contains just one YAM. Also some modules are packaged in so many
ways that it is easier to define their instance data just for that
module. So while packages are an interesting idea they will never
completely replace the module level, hence we need a module level
solution too. One packages are agreed, I will be happy to expand
this specification.
3) YANG library (certainly RFC7895bis) defines the schema in
terms of the datastore, so if this version of YANG library is
being used then it is a bit more confusing as to which datastore
is being referred to. I appreciate that there is a datastore
leaf in the instance data that can help mitigate this.
I also note that the draft currently binds that the only
allowed inline schema is YANG library, but that seems somewhat
overly restrictive, and perhaps this could be loosened to a
leaf-list of inline module@revision definitions?
BALAZS: IMHO ietf-yang-library contains ll the data we need in a
well defined format (and some we don't always need). So why define a
new format when we already have one. Also by using YANG library we
get for free any new data in it e.g.module-version. We also need the
info about leafs and deviations.
I also appreciate that you don't want to delay the instance
data draft for YANG packages, bit I wonder whether the draft can
easily facilitate using a YANG package definition in future if
required.
BALAZS: As I agree with your comment about choice (see below) that a
package reference can be easily included in that.
Hence, rather than using a union for the "target pointer", I
wonder whether it wouldn't be better to use a choice statement
instead.
E.g. the choice statement could be something like this:
choice "schema"
leaf-list inline {
type string {
pattern '\w+@\d{4}-\d{2}-\d{2}\.yang';
}
}
leaf yang-library-ref { type uri } // Points to a
instance data document YANG library content.
}
In future, the package draft could then augment (or update the
revision) with something like this :
container package-ref {
leaf "name" { type string; }
leaf "version" { type yang-semver; }
leaf-list "url" { type uri; } //
Points to a instance data document containing YANG package
content.
}
BALAZS: OK, choice maybe a better choice because it is easier
to extend and because it explicitly states the method used. So
how about:
choice "target-specification"
leaf inline {
type string { pattern 'ietf-yang-library@\d{4}-\d{2}-\d{2}\.yang'; } // I still want to use the library
}
leaf yang-library-ref { type uri }
}
Later we can augment this choice with container package-ref.
Thanks,
Rob
On 06/12/2018 10:15, Balázs Lengyel
wrote:
Hello,
We uploaded a new version of the instance data draft. We
tried to address all comments and also to rework the format
chapter to make it easier to read. We omitted 2 comments:
Rob commented that YANG packages could be used for defining
the target modules for instance data: I would like to avoid
that because:
- Packages are not defined for YANG. Currently they are not
part of the versioning solution even though they were
discussed and are generally a good idea.
- IMHO as deviations/features are set on module level, just
specifying packages would not be enough. If we start using
package+module level deviations/features we may end up with
a more complicated hybrid solution.
- Module level YANG target definitions as described in the
draft are simple and need no new design
Jürgen stated that it would be better to use the YANG
XML/JSON encoding as a format instead of referencing the get
operation/request. I might even agree with him, but for 2
reasons I did not follow his idea:
- Currently there is no RFC I could reference either for XML
or JSON. AFAIK even RFC7951 does not define how multiple
modules should be encoded side by side.
- It is not the job of the instance data draft to dictate
how to encode YANG data generally e.g. on the wire.
- The contents of the get operation/request are well defined
regards Balazs
--
Balazs Lengyel Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909 email: balazs.leng...@ericsson.com
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
--
Balazs Lengyel Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909 email: balazs.leng...@ericsson.com