[Taps] John Scudder's No Objection on draft-ietf-taps-arch-18: (with COMMENT)

John Scudder via Datatracker <noreply@ietf.org> Wed, 06 September 2023 20:15 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: taps@ietf.org
Delivered-To: taps@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CEDAC151547; Wed, 6 Sep 2023 13:15:46 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: John Scudder via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-taps-arch@ietf.org, taps-chairs@ietf.org, taps@ietf.org, michawe@ifi.uio.no, michawe@ifi.uio.no
X-Test-IDTracker: no
X-IETF-IDTracker: 11.10.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: John Scudder <jgs@juniper.net>
Message-ID: <169403134630.32014.16789690207220200939@ietfa.amsl.com>
Date: Wed, 06 Sep 2023 13:15:46 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/taps/HA9eTEHoDYkMldxttRkiszV-8qY>
Subject: [Taps] John Scudder's No Objection on draft-ietf-taps-arch-18: (with COMMENT)
X-BeenThere: taps@ietf.org
X-Mailman-Version: 2.1.39
List-Id: "IETF Transport Services \(TAPS\) Working Group" <taps.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/taps>, <mailto:taps-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/taps/>
List-Post: <mailto:taps@ietf.org>
List-Help: <mailto:taps-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/taps>, <mailto:taps-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Sep 2023 20:15:46 -0000

John Scudder has entered the following ballot position for
draft-ietf-taps-arch-18: No Objection

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-taps-arch/



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

# John Scudder, RTG AD, comments for draft-ietf-taps-arch-18
CC @jgscudder

Thanks for this well-written, useful, and readable document. I have just a few
comments, below.

Also, I share Éric and Roman's uncertainty as to whether the status of this
document should be Informational instead of Standards Track.

## COMMENTS

### Introduction, "transport networking"

In your first sentence, you mention "transport networking". Is this a
well-known term of art? It's not familiar to me. If this specific phrasing
isn't required, I suggest re-wording, to avoid overlap with the significant
existing use of "transport network" in our document set (e.g.,
https://datatracker.ietf.org/doc/search?csrfmiddlewaretoken=dckTkmSFjJ0QJaYJbABIW3isgeAcoV3KBMgOtF3L9ZoxIz92cOGOD1N23YCpUnb9&name=Transport+network&sort=&rfcs=on&activedrafts=on&by=group&group=)

### Section 4.1.4, simultaneous open

The final bullet has "For example, if the Local and Remote Endpoints are TCP
host candidates, then a TCP simultaneous open [RFC9293] will be performed".
Surely not *will* be, but *might* be? I presume that in many or maybe even most
cases of rendezvous, one party or the other would happen to go first, and then
what RFC 9293 describes as simultaneous open (both parties launching a SYN at
the same time) wouldn't occur.

### Section 4.1.5, payload of IP packet... or packets?

The first bullet has "Messages are sent in the payload of IP packet. One packet
can carry one or more Messages or parts of a Message." The first sentence
either needs an indefinite article on "IP packet" or for "payload" and "packet"
to be plural. I think probably you mean "payloads of IP packets" since in
general (as the second sentence shows) a message might be split across two or
more IP packets.

Also, is it even necessary to say that messages are IP payloads? What else
would they be?

### Section 4.1.8, multiplexing transport protocols

The first and third paragraphs have "For multiplexing transport protocols, only
Connections within the same Connection Group are allowed to be multiplexed
together."

First, it doesn't seem like this sentence needs to occur twice.

Second, I assume that what you mean is "transport protocols that support
multiplexing", and if that's right I suggest you say it that way since as
written it's ambiguous.

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues.

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments