Re: [netmod] features in import

[Robert Wilton <[e-mail]>]

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:
> Andy Bierman <[e-mail]> 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 <[e-mail]> wrote:
>>
>>> Hi,
>>>
>>> Ladislav Lhotka <[e-mail]> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/netmod
>>>
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod
> .
>