[netconf] ietf-netconf-server and ietf-netconf-client keepalives

Michal Vaško <mvasko@cesnet.cz> Mon, 04 May 2020 16:26 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 93FE13A0C45 for <netconf@ietfa.amsl.com>; Mon, 4 May 2020 09:26:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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_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=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 eGBOR_FNA1uj for <netconf@ietfa.amsl.com>; Mon, 4 May 2020 09:26:29 -0700 (PDT)
Received: from kalendar.cesnet.cz (kalendar.cesnet.cz [IPv6:2001:718:1:1f:50:56ff:feee:34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A10513A0C30 for <netconf@ietf.org>; Mon, 4 May 2020 09:26:16 -0700 (PDT)
Received: by kalendar.cesnet.cz (Postfix, from userid 999) id 42FDF60178; Mon, 4 May 2020 18:26:12 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=kalendar; t=1588609572; bh=L99y6LcM3PigZug+HSwEE1Wtu2ntuzKwmF0IE/W7BU8=; h=To:Date:Subject:From; b=cP66ZsAd0gcqpDiZn7k7D4dN83f4DVKAt3UMQId4wIPLPtkZW6inYf0AjODA+9gdQ MqKvlscOXB8KWt48dicGSSjZzceiAY0n/8VC1Il2Vr99uQeHUQWW3L2TBPtZ7Fu9cH VxkvS/rQzDFU8q24a0Xk7JOVXmu4EoJeKpK4upfI=
Content-Type: text/plain; charset="utf-8"
To: netconf <netconf@ietf.org>
User-Agent: SOGoMail 2.3.23
MIME-Version: 1.0
Date: Mon, 04 May 2020 18:26:12 +0200
Message-ID: <55da-5eb04200-55-78b364@140138202>
X-Forward: 84.42.161.20
From: Michal Vaško <mvasko@cesnet.cz>
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/vpQYrNenZot6yzc4s67mJj0PgYk>
Subject: [netconf] ietf-netconf-server and ietf-netconf-client keepalives
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, 04 May 2020 16:26:32 -0000

Hi,
in the current YANG modules in the drafts, there are 3 types of keepalives defined for both a server and a client. They are SSH, TLS, and TCP keepalives and can be configured separately for each connection (endpoint).

While I understand what TCP keepalive is as it is a feature with exact definition, I am not that positive for SSH nor TLS. I can only assume the keepalive mechanisms from a Call Home [1] server are used. I would appreciate if the modules define the specifics of all these keepalives because otherwise interoperability cannot be guaranteed. Also, the relation to the Call Home RFC itself should probably be mentioned somewhere. Meaning the answers to questions such as whether SHOULD each RESTCONF/NETCONF server use SSH/TLS keepalive even when a TCP keepalive is enabled. I am also not sure about the need for all 3 types of keepalives, needing to specify them for each connection , or allowing to support 2 kinds simultaneously, but that is just my opinion.

Thanks for any feedback. It is also possible I may have missed something/am wrong and I am sorry in that case.

Regards,
Michal

[1] https://tools.ietf.org/html/rfc8071#page-8