Hi Lada,
Please see inline ...
On 31/01/2019 10:41, Ladislav Lhotka wrote:
On Thu, 2019-01-31 at 10:23 +0000, Robert Wilton wrote:
Hi Martin, Andy,
Despite what YANG the language allows, I think that it is much cleaner
use of the language to split types/groupings that are expected to be
shared by other modules into separate "*_types.yang" modules.
But it is not always the case. For example, ietf-routing has a couple of
groupings and typedefs that may be useful for other purposes.
In this case, it would be better for the groupings and types to be in
ietf-routing-types.yang instead.
OK, that has already been published, so "import-only-modules" can be used.
But if you have a module that:
(i) have external typedefs/groupings not in "*_types.yang" module, and
(ii) the server doesn't actually implement that module, and
(iii) some of the types/grouping depend on features, then
(iv) the module could still be "implemented" and deviated.
I'm just not sure how many modules/implementations will really fit into
this category. Are we increasing the complexity of YANG to handle an
obscure corner case? Do all servers/clients handle import-only feature
handling?
Another potential issue is that multiple revisions of import-only modules may be
used while only one revision is permitted for implemented modules.
I'm not convinced that we really want to encourage multiple versions of
the same typedef floating around for a given schema.
For me, the import-by-revision that we have today, is potentially most
useful if a module wants to pull in a specific definition of a
grouping. Possibly it seems like it might have been helpful if the YANG
import statement could have restricted what types of symbols it was
actually importing or dependent on.
Such problems may not be very common but, on the other hand, it may be worth
fixing before 7895bis becomes an RFC.
I'm not arguing against allowing import-only features because of the
7895bis timeline. I'm arguing against them because I'm not sure that
they are worth the extra complexity.
Thanks,
Rob
Lada
I agree with Andy that it is strange to support a feature in a module
that is not itself implemented.
My hope with YANG library-bis is that most implementations can get by
with an empty "import-only-modules" list, and that they can define all
modules (including types only modules) in the "module" list of
implemented modules.
So, I actually think that the workaround using deviations below is OK,
because this scenario should be avoidable by having a clean separation
between external reusable types and implementable nodes.
Thanks,
Rob
On 31/01/2019 08:44, Martin Bjorklund wrote:
Andy Bierman <[email protected]> wrote:
Hi,
I do not agree these changes should be made at this late date.
It seems to me that in order to support a feature you have to implement
it,
and therefore if any features are set then the module is implemented, not
imported.
But this is not what RFC 7950 says about implement:
A server implements a module if it implements the module's data
nodes, RPCs, actions, notifications, and deviations.
All features should be set to false in an import-only module.
IMO this interpretation holds for typedef modules like iana-crypt-hash.
We list that as implemented (because it is) and the features that are
supported are set.
If a module consists only of typedefs, there is no problem.
Conformance "import" or "import-only" modules exist in YL b/c modules
may have a mix of typedefs and data nodes etc.
So in the case that Lada brought up, a server would have to list the
module as implemented with a certain set of features; and then also
deviate all nodes/rpc/notifc etc as 'not-implemented'.
/martin
Andy
On Wed, Jan 30, 2019 at 11:03 AM Martin Bjorklund <[email protected]> wrote:
Hi,
Ladislav Lhotka <[email protected]> wrote:
Hi,
unlike RFC 7895, 7895bis doesn't provide the "feature" leaf list for
import-only modules. But is it really so that features have no use in
such modules?
For example, an enum can depend on a feature, and if it is inside a
typedef, it can also be in an import-only module. What if that feature
is defined in the same module?
I think you're right, and that this is an unfortunate omission.
The fix is simple though; we would have to add the leaf-list features
to import-only. Probably refactor the "feature" leaf-list into a
grouping so it works like the grouping location-leaf-list:
grouping feature-leaf-list {
leaf-list feature {
type yang:yang-identifier;
description
"List of all YANG feature names from this module that are
supported by the server, regardless whether they are defined
in the module or any included submodule.";
}
}
And then "uses feature-leaf-list":
OLD:
grouping module-implementation-parameters {
description
"Parameters for describing the implementation of a module.";
leaf-list feature {
type yang:yang-identifier;
description
"List of all YANG feature names from this module that are
supported by the server, regardless whether they are defined
in the module or any included submodule.";
}
NEW:
grouping module-implementation-parameters {
description
"Parameters for describing the implementation of a module.";
uses feature-leaf-list;
And in the list "import-only":
OLD:
uses location-leaf-list;
uses feature-leaf-list;
/martin
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
.
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
