Re: [netconf] why did we breakout the groupings?

Kent Watsen <kent+ietf@watsen.net> Sat, 23 March 2019 18:35 UTC

Return-Path: <01000169abd5f928-cf7dab92-f351-4eb7-a9b4-90d1ee7477d3-000000@amazonses.watsen.net>
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 28660128766 for <netconf@ietfa.amsl.com>; Sat, 23 Mar 2019 11:35:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com
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 Ghw9VK0CzwTS for <netconf@ietfa.amsl.com>; Sat, 23 Mar 2019 11:35:22 -0700 (PDT)
Received: from a8-33.smtp-out.amazonses.com (a8-33.smtp-out.amazonses.com [54.240.8.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31AB1128D0B for <netconf@ietf.org>; Sat, 23 Mar 2019 11:35:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1553366120; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=Yfg3XBjlRsBQxEFsgehdoa8kD9F747lA3GiTwulQjnQ=; b=lrEWIw+lcFASiwVEqA96mdW52kpQ4ZsRJzQEEW1XZgeZAmAY9DO5tmQ0i5Gy6uR8 1z9+L46+VspFeV9IPFrUhrg3xN2FEc9ag76D5eCvCaksQPuCxLayTEAhiV/sv8p8Rrq bVvbRN+9OrVEbRgYYL4fZcZtbAkwXVc5dNhEOMwQ=
Content-Type: multipart/alternative; boundary=Apple-Mail-6BD8924F-2179-4095-A066-AD9FBCC85CF3
Mime-Version: 1.0 (1.0)
From: Kent Watsen <kent+ietf@watsen.net>
X-Mailer: iPad Mail (16D57)
In-Reply-To: <VI1PR07MB4735B4C1AF014281AB693E5E83430@VI1PR07MB4735.eurprd07.prod.outlook.com>
Date: Sat, 23 Mar 2019 18:35:20 +0000
Cc: "netconf@ietf.org" <netconf@ietf.org>
Content-Transfer-Encoding: 7bit
Message-ID: <01000169abd5f928-cf7dab92-f351-4eb7-a9b4-90d1ee7477d3-000000@email.amazonses.com>
References: <01000169a0becf2a-5f004be0-a74d-4f9b-b456-f8c3309fac94-000000@email.amazonses.com> <VI1PR07MB4735B4C1AF014281AB693E5E83430@VI1PR07MB4735.eurprd07.prod.outlook.com>
To: =?utf-8?Q?Bal=C3=A1zs_Kov=C3=A1cs?= <balazs.kovacs@ericsson.com>
X-SES-Outgoing: 2019.03.23-54.240.8.33
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/BYl6PKnvPLsP71-IcaMEsq7nNC8>
Subject: Re: [netconf] why did we breakout the groupings?
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: Sat, 23 Mar 2019 18:35:24 -0000

Hi Balazs,

Thank you for including the thread from before.  I lost my old inbox and hadn’t gotten around to searching the archives.

Upon re-reading the thread, I see again that the intent was to support interactive SSH clients with partial configuration.  That is, you wished to persist some aspects while allowing other aspects be bound more dynamically.

This being the case, I’m wondering if an alternate solution may have been to persist dummy values to be replaced by variable substitution (e.g. remote-address = “REMOTE-ADDRESS”, username = “USERNAME”, etc.)?   Being interactive, the code is not autonomously running in the background and thus can be instrumented to inject user-specified values.  Thoughts?    Since “port” is a number, the value “PORT” cannot be persisted, but maybe MAX port value could be reserved for this purpose, or an “overlay” schema could be used to provide an alternate hook?

You’re correct that the breakouts seem to do no harm, but I learned a long time back that groupings SHOULD NOT be made indiscriminately.   Given that you say that you’re no longer using these breakout groupings, and the previous paragraph suggests workarounds are possible (agreed?), I believe we should revert to the previous approach with no breakout groupings, if there are no objections, of course (do you?).

PS: there is a bullet point in my presentation on this; I plan to refer to this thread and ask again if there are any objections.

Kent // contributor


> On Mar 22, 2019, at 2:01 PM, Balázs Kovács <balazs.kovacs@ericsson.com>; wrote:
> 
> Hi Kent,
>  
> We had the attached conversation.
>  
> Since we had this change, I admit I refrained from using the client-identity-grouping separately from an endpoint configuration (see attached mail). Allowing the option for interactive selection of client identity did not seem to be that good idea after all. I cannot say now I have any intention to use them separately in the close future.
>  
> From your feedback I so far understood that these sub-grouping do not harm much since the client-server models can use the original grouping, such as the ‘ssh-client-grouping’.
>  
> All in all, I think I do not mind if you collapse this back into a single grouping if there is no other need to keep them separate.
>  
> Br,
> Balazs
>  
>  
>  
> From: Kent Watsen <kent+ietf@watsen.net>; 
> Sent: Thursday, March 21, 2019 3:54 PM
> To: Balázs Kovács <balazs.kovacs@ericsson.com>;
> Cc: netconf@ietf.org
> Subject: why did we breakout the groupings?
>  
> Hi Balazs,
>  
> I'm in the middle of answering your other question when I was reminded that I've been meaning to follow up with you on this issue...
>  
> Can you please help me recall why several months back we made the decision to redefine the ietf-ssh-[client/server]-grouping statements to use other groupings?  For instance, here's the current definition:
>  
>     grouping ssh-client-grouping {
>        uses client-identity-grouping;
>        uses server-auth-grouping;
>        uses transport-params-grouping;
>        uses keepalives-grouping;
>      }
>  
> Obviously it was because you (I think it was you) wanted to be able to "use" the inner grouping in another context, but why?
>  
> I ask because this strategy is percolating into all of the client/server models and it seems weird, if not wrong.  I currently have it as an "open issue" in my presentation for Monday, but I'd rather resolve it offline/now if possible.
>  
> Kent // contributor
>  
>  
>  
> <mime-attachment>