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

[Andy Bierman <[e-mail]>]

On Thu, May 27, 2021 at 12:05 PM Kent Watsen <[e-mail]> wrote:

> [moving all alias except “netconf” to the BCC list]
>
>
> Hi Andy,
>
> Thank you for your review!
>
>
> > On May 25, 2021, at 3:22 PM, Andy Bierman via Datatracker <
> [e-mail]> wrote:
> >
> > Reviewer: Andy Bierman
> > Review result: Ready
> >
> > Comments:
> >
> > I am not commenting on the TLS 1.0 and 1.3 onging discussions.
> > The WG decision does not impact the YANG module review.
> >
> > 1) Measuring Interoperability for groupings and identities
> >
> > [same comment for SSH and TLS drafts]
> >
> > These modules are intentionally abstract.
> > There are no protocol-accessible objects defined at all.
> > Interoperability is usually measured in the context of a
> > specific protocol (e.g., NETCONF).
> >
> > There is an assumption that interoperability will be achieved
> > by some other RFCs that will have "uses" statements to create
> > protocol-accessible or otherwise implementable objects.
> >
> > There is also an assumption that the groupings will be used the
> > same everywhere, and the only difference will be the
> > path from root to the objects in these groupings.
> > In fact, the "refine" statement allows each usage to be
> > different.
> >
> > Perhaps the drafts should mention these interoperability issues.
>
> Let’s discuss this in my response to the same comment in your review of
> the ssh-client-server draft.
>
>
> > 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?


> K.
>


Andy