Re: [netmod] features in import

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.

Another potential issue is that multiple revisions of import-only modules may be
used while only one revision is permitted for implemented modules.

Such problems may not be very common but, on the other hand, it may be worth
fixing before 7895bis becomes an RFC.

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 <andy@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'.
> > 
> > 
> > /martin
> > 
> > > Andy
> > > 
> > > On Wed, Jan 30, 2019 at 11:03 AM Martin Bjorklund <mbj@tail-f.com> wrote:
> > > 
> > > > Hi,
> > > > 
> > > > Ladislav Lhotka <lhotka@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
> > .
> > 
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67