Re: [netmod] features in import

[Robert Wilton <[e-mail]>]

Hi Lada,

Please see inline ...

On 31/01/2019 10:41, Ladislav Lhotka wrote:
> 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.

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?


>
> Another potential issue is that multiple revisions of import-only modules may be
> 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.


>
> Such problems may not be very common but, on the other hand, it may be worth
> 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


>
> 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 <[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
>>> .
>>>
>> _______________________________________________
>> netmod mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/netmod