Subject: [netmod] features in import

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 30 Jan 2019 16:17:23 +0100

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?

Lada

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 30 Jan 2019 20:02:50 +0100 (CET)

Hi,

> 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

---

From: Andy Bierman <[email-masked]>
Date: Wed, 30 Jan 2019 16:39:12 -0800

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.
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.

Andy

On Wed, Jan 30, 2019 at 11:03 AM Martin Bjorklund <[email-masked]> wrote:

> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 31 Jan 2019 09:44:07 +0100 (CET)

> and therefore if any features are set then the module is implemented, not

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.

> We list that as implemented (because it is) and the features that are

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

---

From: Robert Wilton <[email-masked]>
Date: Thu, 31 Jan 2019 10:23:29 +0000

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.

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:
> .

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 31 Jan 2019 11:41:01 +0100

> 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

---

From: Andy Bierman <[email-masked]>
Date: Thu, 31 Jan 2019 02:46:15 -0800

> 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.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 31 Jan 2019 11:58:28 +0100 (CET)

> A server has to implement a feature to advertise it.

As per 7950, this is not true, as I pointed out earlier.

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).

/martin

---

From: Robert Wilton <[email-masked]>
Date: Thu, 31 Jan 2019 11:04:16 +0000

Hi Lada,

Please see inline ...

> 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?

> 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.

> 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

---

From: Robert Wilton <[email-masked]>
Date: Thu, 31 Jan 2019 11:13:41 +0000

> import-only module.  The new YL removes this possibility (by

This presumably also means that clients/servers also have to handle the 
fact that different features can be advertised for each revision of an 
import-only module that has been imported.

Thanks,
Rob

---

From: Andy Bierman <[email-masked]>
Date: Thu, 31 Jan 2019 07:32:20 -0800

On Thu, Jan 31, 2019 at 2:58 AM Martin Bjorklund <[email-masked]> wrote:

> > > > It seems to me that in order to support a feature you have to
> implement
> > > it,
I think 7950 is wrong then

> import-only module.  The new YL removes this possibility (by
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.

Andy