[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 <noreply@xxxxxxxx> 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.”;
K.
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
