Re: [netconf] Latest ietf-netconf-server draft and related modules

Kent Watsen <> Wed, 21 April 2021 00:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 43DA43A0DF6 for <>; Tue, 20 Apr 2021 17:57:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IcimByPIlMIk for <>; Tue, 20 Apr 2021 17:57:42 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3D32F3A0DEA for <>; Tue, 20 Apr 2021 17:57:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug;; t=1618966660; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=K1ps5Qk3nXTCOfSUYGRhHDyNwvVhc9wp/2YIVXfNjpI=; b=KeB/uPFVKcMEWIAeUg5CsZRplyObh2qZun/kBYj7deNlxzNXXyuXLRlggqjqycw7 bw0KaS5EmWAqm19E+UiEBhmQgexbwlDsb6cKkfmrhi/7ycwUM0QZZlkZUPhzihJjpoV JYj3n/Vx9Yz3+tJe8+j2j6UxwqlShwhiJR5sD9A0=
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
From: Kent Watsen <>
In-Reply-To: <1104-607e6b00-3-2fba9200@222555441>
Date: Wed, 21 Apr 2021 00:57:40 +0000
Cc: "" <>
Content-Transfer-Encoding: quoted-printable
Message-ID: <>
References: <1104-607e6b00-3-2fba9200@222555441>
To: Michal Vaško <>
X-Mailer: Apple Mail (2.3654.
X-SES-Outgoing: 2021.04.21-
Archived-At: <>
Subject: Re: [netconf] Latest ietf-netconf-server draft and related modules
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 21 Apr 2021 00:57:46 -0000

Hiya Michal,

Please see below…


For this response:

> I am using only the "keyboard-interactive"  method and only as a user, so I do not have in-depth knowledge. However, it seems fine and should be now configurable, thanks! Like I said, I cannot say much about the "gssapi" methods, never used them. But they also seems fine to me.

And this response:

> We are not using them (yet) as the last draft we implemented was still missing some features. Looking at it now, it seems okay.

My understanding that you “think" these updates are okay, which is greatly appreciated (your considerations, that is).   It would be perfect if you could actually try them out before this work gets published...

FWIW, my guess is that there’s at least a month until the netconf-client-server and restconf-client-server drafts complete their WGLCs, assuming they get kicked off in the next week or two as expected, and then we will quickly reach the point where it will be too late for anymore easy “do-overs”.

> An improvement I can think of is to put all the authentication methods in "users/user" in a mandatory choice. The authentication methods would be one case, while something like "global-config" (empty leaf, for example) would be the other. That should allow for maximum versatility when one could configure the 'global authentication methods', enable the "client-auth-config-supported" feature to configure the recognized users, but use the global authentication methods settings for some/all the users (not having to configure each one separately). Because that will probably be our use-case.

Could you provide a tree diagram snippet that illustrates this?  Regarding your last sentence, I imagine that that might be many folks use-case.  That is, the actual user-auth might be somewhere else (e.g., PAM, LDAP, etc.); it might be rare thing that folks would want to config users inside the “ssh-server-grouping”.

The following regards the "tls-listen or tls-call-home or sshcmn:ssh-x509-certs” if-feature statement:
>> But I wasn’t trying to fix your original issue.  As mentioned, there is a YANG-next issue and the best that consuming modules can do is to 1) enable all the features defined in these modules and 2) augment-in “use”-specific feature statements where the groupings are used.
> Okay, I suppose this can be done although it seems to me like a minor deviation (the augment solution). What is the reason for not having the module this way out-of-the-box?

It might be helpful to recall that this “if-feature” statement is in the netconf-client-server draft, and thus likely should be discussed in another thread.  That said, we’ve come so far already, so why not a little more, right?  ;)

So, do you have a proposal mind?