Re: [netconf] [Last-Call] Yangdoctors last call review of draft-ietf-netconf-tls-client-server-24

[Andy Bierman <[e-mail]>]

On Tue, Jun 1, 2021 at 6:32 AM Kent Watsen <[e-mail]> wrote:

> Hi Andy,
>
>
> > 2)  mandatory choice of only optional-to-implement cases
>> >
>> > The choice /ietf-tls-client:client-identity/auth-type
>> > is mandatory but all cases have if-feature-stmts.
>> > Does draft mention 1 of the 4 features MUST be implemented?
>>
>>
>>
>> The same construct is present in the ietf-tls-server module as
>> well...I’ll apply the agreed upon solution to both.  Would the following
>> update suffice?
>>
>> OLD:
>>
>>       choice auth-type {
>>         mandatory true;
>>         description
>>           "A choice amongst authentication types.”;
>>
>> NEW:
>>
>>       choice auth-type {
>>         mandatory true;
>>         description
>>           "A choice amongst authentication types, of which one must
>>            be enabled (via its associated 'feature') and selected.”;
>>
>>
>>
>
> Related issue:
>
> What is a server supposed to do if it is implementing a module with
> a configuration that has a mandatory choice but no enabled or defined
> cases?
>
> A) add a deviation to remove the mandatory-stmt
> B) always return a data-missing error and block the edit or commit
> C) ignore the error and treat it as a NO-OP
> D) something else?
>
>
> My server doesn’t detect the logical fallacy at startup but, of course,
> will fail any configuration attempt due to a validation error.
>
> The assumption is that implementations will choose which features to
> support in the course of development.
>
> From the perspective of a toolkit like YumaPro, where end-users
> selectively enable features themselves, the two choices I see are: 1) no
> special logic, as they’ll discover the validation error soon enough or, 2)
> add special logic to catch the logical fallacy and fail startup until
> resolved.
>
>
I see your point.
A developer should never ship a server that would have this issue.

YANG developers need to be careful about defining choice-stmts with no
enabled case-stmts.
This is a fairly common practice (e.g. relying on augment from another
module to provide the case-stmts).
>From the client developer POV, it is bad to assume the augmenting module(s)
will be present.
(This is a use-case for YANG packages I guess).


> Andy
>
>
Andy


>
> K.
>
>
>
>