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

From: Kent Watsen <[email-masked]>
Date: Tue, 1 Jun 2021 13:32:44 +0000

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.

> Andy

K.

---

From: Andy Bierman <[email-masked]>
Date: Tue, 1 Jun 2021 10:15:26 -0700

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

>> 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
> My server doesn’t detect the logical fallacy at startup but, of course,
> will fail any configuration attempt due to a validation error.
>
> 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