[netconf] Yangdoctors last call review of draft-ietf-netconf-tcp-client-server-09

Ladislav Lhotka via Datatracker <noreply@ietf.org> Fri, 09 April 2021 09:58 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 2A1943A1ACB; Fri, 9 Apr 2021 02:58:30 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Ladislav Lhotka via Datatracker <noreply@ietf.org>
To: <yang-doctors@ietf.org>
Cc: draft-ietf-netconf-tcp-client-server.all@ietf.org, last-call@ietf.org, netconf@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.27.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <161796231010.8005.7390142571009530431@ietfa.amsl.com>
Reply-To: Ladislav Lhotka <ladislav.lhotka@nic.cz>
Date: Fri, 09 Apr 2021 02:58:30 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/BbH3yOm2xJDUfv1jN5-CvYwt88A>
Subject: [netconf] Yangdoctors last call review of draft-ietf-netconf-tcp-client-server-09
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
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: Fri, 09 Apr 2021 09:58:30 -0000

Reviewer: Ladislav Lhotka
Review result: Ready with Issues

The modules are well designed and nicely documented, both in the descriptions
and text of the Internet-Draft.

**** Comments

- Sections 2.1.4, 3.1.3, 4.1.3: the sentence 'The "..." module does not contain
any protocol-accessible nodes.' is misleading in that the modules do define
data nodes that are intended to be protocol accessible after the corresponding
grouping is used. I know this is a part of the NETCONF/YANG lingo, but another
formulation that clearly says what's going on might be preferable.

- Sections 2.2, 3.2 and 4.2: the XML snippets use document elements
"tcp-common", "tcp-client" and "tcp-server", but these containers are not
defined in the corresponding modules. This is confusing, my suggestion is to
rewrite the examples in the JSON representation where no such top-level node is
necessary.

- What is the purpose of "tcp-connection-grouping" if it only uses
"tcp-common-grouping" and nothing else? Why cannot "tcp-common-grouping" be
used directly?

- The "local-port" parameter defined in ietf-tcp-client seems dubious from the
security viewpoint in that fixing the source port makes it easier for attackers
to steal the connection (see RFC 6056). If the feature
"local-binding-supported" is needed at all, I'd suggest to mention this in
Security Considerations.

- The module ietf-tcp-client uses the placeholder "RFC AAAA", which is not
defined in the Editorial Note.

**** Nits

- RFC 7950 is cited repeatedly (6 times) in a general context, e.g. whenever
YANG 1.1 is mentioned. It should suffice to use the citation at the first
appearance.

- sec. 1.3: s/in compliant/is compliant/

- in 3 places: s/illustatrating/illustrating/