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

[Kent Watsen <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]> 
> Sent: Thursday, March 21, 2019 3:54 PM
> To: Balázs Kovács <[e-mail]>
> Cc: [e-mail]
> 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>