On Thu, Jan 31, 2019 at 2:58 AM Martin Bjorklund <m...@tail-f.com> wrote:
> Andy Bierman <a...@yumaworks.com> wrote:
> > 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.
>
> As per 7950, this is not true, as I pointed out earlier.
>
>
I think 7950 is wrong then
> Note that with current YL (RFC 7895), it *is* in fact possible to
> handle this case; you can list the features supported for an
> import-only module. The new YL removes this possibility (by
> mistake).
>
>
It is not a mistake.
The draft was reviewed 100 times.
It looks intentional.
I still don't understand the logic behind implementing a feature in a
module you don't implement.
There are plenty of cases (augment) where the imported module must also be
an implemented module. Not sure what problem is solved by listing the
module with
features as a real module.
I don't think the new YL should be changed at this late date.
>
> /martin
>
Andy
>
>
> > 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
