Re: [netconf] WGLC on draft-ietf-netconf-ssh-client-server

Michal Vaško <mvasko@cesnet.cz> Mon, 29 March 2021 06:37 UTC

Return-Path: <mvasko@cesnet.cz>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FFC73A0CAC for <netconf@ietfa.amsl.com>; Sun, 28 Mar 2021 23:37:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cesnet.cz
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t6Qb7kXz4qxh for <netconf@ietfa.amsl.com>; Sun, 28 Mar 2021 23:37:44 -0700 (PDT)
Received: from kalendar.cesnet.cz (kalendar.cesnet.cz [78.128.211.34]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AAFB3A0CA7 for <netconf@ietf.org>; Sun, 28 Mar 2021 23:37:43 -0700 (PDT)
Received: by kalendar.cesnet.cz (Postfix, from userid 110) id AC7296007A; Mon, 29 Mar 2021 08:37:38 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=kalendar; t=1616999858; bh=U1OZRgARknwdKTPGVk00gulUgb8n4FGLcQx+62yQ8+c=; h=From:In-Reply-To:Date:Cc:To:Subject; b=5My4gNelQgKi9iE3qUS1EZCY9smY9v+v4IDrOVFdbu834KntI0cxNG98H8q37ogw+ IATYrfHommJUgKwLeu39LCTjqLyywa56keAniEYb4g2Z74TKSKgnBGp6bGsWzjfwgb UO8ajZlWNt7HKKa8TlFkOw3siRKH5SUvc1paYtBc=
From: Michal Vaško <mvasko@cesnet.cz>
In-Reply-To: <EE9F9FF2-EF03-4929-9C4A-B34634135686@gmail.com>
Content-Type: text/plain; charset="utf-8"
X-Forward: 84.42.188.124
Date: Mon, 29 Mar 2021 08:37:38 +0200
Cc: netconf@ietf.org
To: Mahesh Jethanandani <mjethanandani@gmail.com>
MIME-Version: 1.0
Message-ID: <451-60617580-a3-57300800@87220951>
User-Agent: SOGoMail 5.0.1
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/1H6BegfEpZmNrjO5n9Nuh_0J_Xs>
Subject: Re: [netconf] WGLC on draft-ietf-netconf-ssh-client-server
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Mar 2021 06:37:49 -0000

Hi,

I have raised some questions regarding this draft on the 5th of March and even though I got the email bounced back from netconf@ietf.org, I did not get any replies and cannot find it in the archive. In any case, the original email is below.

I had a chance to look at these modules again and have 2 questions regarding some recent changes.

- ietf-ssh-server, ssh-server-grouping/client-authentication/supported-authentication-methods

Since the "other" leaf-list was removed there is no way to support some other methods than those specified. I am not sure whether this was the intention and if so, what is the reason for it? If nothing else, we support "interactive" authentication method but there are some others that I see no reason why they could not be used. For a robust and extendible solution, why not use an identityref leaf-list with all the methods as identities? One could then simply add new ones with specific "if-feature" statements.

- ietf-netconf-server, grouping netconf-server-grouping/client-identity-mappings

The "if-feature" on this container is strange. The practical problem is that if one wants to support certificates only for TLS, both one of the TLS features and "ssh-x509-certs" must be enabled. This then results in the container being defined for both SSH and TLS so there is no way to support it only for TLS or SSH.

Thanks for any input.

Regards,
Michal

On Friday, March 26, 2021 23:30 CET, Mahesh Jethanandani <mjethanandani@gmail.com> wrote: 
 
> We are starting a 2 week WGLC for draft-ietf-netconf-ssh-client-server version 23.
> 
> https://datatracker.ietf.org/doc/draft-ietf-netconf-ssh-client-server/ <https://datatracker.ietf.org/doc/draft-ietf-netconf-sztp-csr/>
> 
> Please respond on this thread indicating your support or concerns about why this document should/should not be adopted.
> 
> We are particularly interested in statement of the form:
> 
> - I have reviewed the draft and found no issues. 
> - I have reviewed the draft and found the following issues …
> 
> This WGLC will conclude on Friday, April 9. An IPR call will be issued separately.
> 
> Thank you.
> 
> Mahesh & Kent (as co-chairs)
> 
> 
> 
> 
> 
>