[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
- [Taps] John Scudder's No Objection on draft-ietf-… John Scudder via Datatracker