Re: [netconf] [Last-Call] Yangdoctors last call review of draft-ietf-netconf-ssh-client-server-24

Kent Watsen <kent@watsen.net> Thu, 27 May 2021 19:05 UTC

Return-Path: <01000179af378320-73241cbb-c5a4-45dd-8c87-03ff603cc2f0-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 D4C263A07AB; Thu, 27 May 2021 12:05:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.894
X-Spam-Level:
X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=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 5Ac-5cgsABs2; Thu, 27 May 2021 12:05:26 -0700 (PDT)
Received: from a48-110.smtp-out.amazonses.com (a48-110.smtp-out.amazonses.com [54.240.48.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3A063A07A4; Thu, 27 May 2021 12:05:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1622142321; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=Y5HzRcAqOnoXwQe66cWxjccTgEbcCxJR4aKH8wYAqGQ=; b=JQTpEc3EpTGs6pCNO3EmoiXwfQti0lydfTs4aEQlDTXQrb3eQrpZmB8cYvGq2ow3 puostXynMfrXkQz9Pjp7ZmoX/V0hEL0gkrEahnbH9KWQR1HpUZkdVKmm8nDghj89oW+ OzeBupDHh9jSWTGmKtvUQmpTEAgRHEwMzQMD1qCg=
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\))
From: Kent Watsen <kent@watsen.net>
In-Reply-To: <162197047222.6755.5719177112947542346@ietfa.amsl.com>
Date: Thu, 27 May 2021 19:05:21 +0000
Cc: "netconf@ietf.org" <netconf@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-ID: <01000179af378320-73241cbb-c5a4-45dd-8c87-03ff603cc2f0-000000@email.amazonses.com>
References: <162197047222.6755.5719177112947542346@ietfa.amsl.com>
To: Andy Bierman <andy@yumaworks.com>
X-Mailer: Apple Mail (2.3654.60.0.2.21)
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
X-SES-Outgoing: 2021.05.27-54.240.48.110
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/vKRxwLNXcDlCJtkxJh1LgDIxMSs>
Subject: Re: [netconf] [Last-Call] Yangdoctors last call review of draft-ietf-netconf-ssh-client-server-24
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: Thu, 27 May 2021 19:05:31 -0000

[moving all alias except “netconf” to the BCC list]


Hi Andy,

Thank you for your review!

> On May 25, 2021, at 3:21 PM, Andy Bierman via Datatracker <noreply@ietf.org> wrote:
> 
> Reviewer: Andy Bierman
> Review result: Ready
> 
> Comments:
> 
> 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.

True, and we have, e.g., the "netconf-client-server" and "restconf-client-server" drafts, and the PCE WG has the "pcep-yang” draft.   There’s a leap of faith, but also some running code, so hopefully within the intentions of an “RFC”.


> 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.

What assumption?  Do you mean the description statements in the various "[ssh/tls]-[client/server]-grouping” groupings.  For instance, see the 2nd paragraph below:

     grouping ssh-client-grouping {
       description
         "A reusable grouping for configuring a SSH client without
          any consideration for how an underlying TCP session is
          established.

          Note that this grouping uses fairly typical descendent
          node names such that a stack of 'uses' statements will
          have name conflicts.  It is intended that the consuming
          data model will resolve the issue (e.g., by wrapping
          the 'uses' statement in a container called
          'ssh-client-parameters').  This model purposely does
          not do this itself so as to provide maximum flexibility
          to consuming models.";

While it is true that “stacks” (or sibling “uses” statements) are expected (from a "best practice” POV), I’m unaware of any Xpath expressions enforcing this.


> Perhaps the drafts should mention these interoperability issues.

Could you be more specific in what text you’d like to see in which sections?



> 2) same feature names in 2 modules
> 
>  - feature userauth-hostbased
>  - feature userauth-none
>  - feature userauth-password
>  - feature userauth-publickey
> 
> The ietf-ssh-client and ietf-ssh-server modules both use these
> feature names. IMO users will not expect this, and this will cause
> confusion.
> 
> Why can't these features be defined once in ietf-ssh-common.yang?
> Seems like client and server will advertise the feature for
> implementing their relevant values.

Well, these were named differently in just the previous version of the ssh draft…from the change log:

 *  Renamed "client-auth-*" to "userauth-*"
 *  Renamed "client-identity-*" to "userauth-*”

Juergen felt that these were more natural names for SSH.   I agreed, mostly just to get the “monkey off my back”, but it breaks with the convention used by the collection if client-server drafts (where all the variations of "[client/server]-[auth/identity]” are typically used).  

Yes, “userauth” is the term used in the SSH drafts, and I didn’t think is was a big deal or, really, any deal at all, for the same feature names to be used in both drafts, such that I'm surprised by your "users will not expect this, and this will cause confusion” comment...

Moving the definitions to the “common” module is possible, of course, but tricky since the description statements say different things, to address the different contexts in which they’re used.  The description statement could be expanded to address each context, but this will get wordy…I wonder if it wouldn’t be better to just go back to the previous “client-[auth/identity]-*” prefixes - thoughts?




K.