On Thu, Jan 31, 2019 at 12:44 AM Martin Bjorklund <m...@tail-f.com> wrote:
> Andy Bierman <a...@yumaworks.com> 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'.
>
>
So what. Using deviate(not-supported) to cherry-pick what you want to
implement
out of a module is how it is supposed to work.
A server has to implement a feature to advertise it.
Therefore the module containing the feature cannot be import-only.
> /martin
>
>
Andy
> >
> >
> > Andy
> >
> > On Wed, Jan 30, 2019 at 11:03 AM Martin Bjorklund <m...@tail-f.com>
> wrote:
> >
> > > Hi,
> > >
> > > Ladislav Lhotka <lho...@nic.cz> 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
> > > netmod@ietf.org
> > > https://www.ietf.org/mailman/listinfo/netmod
> > >
>
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
