[netconf] Éric Vyncke's Discuss on draft-ietf-netconf-tcp-client-server-21: (with DISCUSS and COMMENT)

Éric Vyncke via Datatracker <noreply@ietf.org> Tue, 20 February 2024 12:55 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: netconf@ietf.org
Delivered-To: netconf@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BCDDEC151065; Tue, 20 Feb 2024 04:55:37 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Éric Vyncke via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-netconf-tcp-client-server@ietf.org, netconf-chairs@ietf.org, netconf@ietf.org, perander@cisco.com, mjethanandani@gmail.com, perander@cisco.com
X-Test-IDTracker: no
X-IETF-IDTracker: 12.5.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Éric Vyncke <evyncke@cisco.com>
Message-ID: <170843373775.28810.15163380629330089098@ietfa.amsl.com>
Date: Tue, 20 Feb 2024 04:55:37 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/GLfFl9AzyUFI_2Kip4nNa5QNlOg>
Subject: [netconf] Éric Vyncke's Discuss on draft-ietf-netconf-tcp-client-server-21: (with DISCUSS and COMMENT)
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.39
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: Tue, 20 Feb 2024 12:55:37 -0000

Éric Vyncke has entered the following ballot position for
draft-ietf-netconf-tcp-client-server-21: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netconf-tcp-client-server/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------


# Éric Vyncke, INT AD, comments for draft-ietf-netconf-tcp-client-server-21

Thank you for the work put into this document.

Please find below one blocking DISCUSS points (easy to address as it is only to
force a reply), some non-blocking COMMENT points (but replies would be
appreciated even if only for my own education).

Special thanks to Per Andersson for the shepherd's detailed write-up including
the WG consensus (and the discussion with TCPM) and the justification of the
intended status.

I hope that this review helps to improve the document,

Regards,

-éric

# DISCUSS (blocking)

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a
DISCUSS ballot is a request to have a discussion on the following topics:

## No MASQUE or HTTP-proxy defined ?

This is mainly to force a discussion over email. SOCKS were (and probably are
still) a common proxy mechanism, but should SSH tunnels, MASQUE connect (and
its old parent HTTP connect method) be part of this document?


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


# COMMENTS (non-blocking)

## Section 2.1

While the text about keep-alives use cases sounds correct, I wonder whether
this text is relevant in an I-D about *data models*, i.e., why discussing the
semantics and use cases of TCP keep-alives?

Some issue with the use of normative language for the default values of TCP
keep-alives, those values SHOULD be in NETCONF/RESTCONF protocols and not
discussed in this data model. To be honest, I hesitated to raise a discuss
level on this.

## Section 3.1.2.1

The reader would probably welcome an explanation of the differences between
'socks4' and 'socks4a', is it only to allow for a hostname ?

Should it be possible to configure multiple remote-addresses for the proxy ?

## Section 3.3

About the tcp-client-grouping remote-address `the IP addresses are tried
according to local preference order`, should there be a reference to RFC 6724
(as there can be multiple source addresses) ?

Also in tcp-client-grouping local-address, AFAIK `INADDR6_ANY
('0:0:0:0:0:0:0:0' a.k.a. '::')` also means supporting IPv4-mapped addresses
per RFC 4291. SO, the text `the server can bind to any IPv4 or IPv6 addresses,
respectively ` should be amended.

## Section 4.3

Also in tcp-server-grouping local-address, AFAIK `INADDR6_ANY
('0:0:0:0:0:0:0:0' a.k.a. '::')` also means supporting IPv4-mapped addresses
per RFC 4291. SO, the text `the server can bind to any IPv4 or IPv6 addresses,
respectively ` should be amended.