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

Warren Kumari via Datatracker <noreply@ietf.org> Tue, 05 September 2023 23:41 UTC

MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Warren Kumari 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, dd@dhruvdhody.com, ops-dir@ietf.org
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Warren Kumari <warren@kumari.net>
Message-ID: <169395728851.60878.10879112817343812369@ietfa.amsl.com>
Date: Tue, 05 Sep 2023 16:41:28 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/taps/RLn25eRCeupFNEeYaJYW0ApmV24>
Subject: [Taps] Warren Kumari's No Objection on draft-ietf-taps-arch-18: (with COMMENT)

Warren Kumari 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:
----------------------------------------------------------------------

Firstly, thank you very much for writing this document -- I found it a
fascinating read.

Like Rob, I'd like to thank Druv for the excellent initial Ops-Dir review
(https://datatracker.ietf.org/doc/review-ietf-taps-arch-17-opsdir-lc-dhody-2023-04-14/
), and then the followup
(https://datatracker.ietf.org/doc/review-ietf-taps-arch-18-opsdir-telechat-dhody-2023-08-26/)

I only have a few nits / suggestions to make:
1: S 1.4. Glossary of Key Terms
*Endpoint: An identifier for one side of a Connection (local or
remote), such as a hostnames or URL.

I'm not really sure that the definition of "Endpoint" works. E.g: the
definition of "Connection" is "Shared state of two or more endpoints that
persists across Messages". Ok, fine. But can you really have shared state
between two **identifiers**? I don't really see how I'd have shared state
between e.g hostnames, but I can see how I'd have state between entities
*identified* by an identifier like a hostname. I understand what you are aiming
for (and also "endpoint" seems to be used in more than one context), but I
don't think that the definition as written actually works...

2: S 2.1. Event-Driven API
This paragraph compares and contrasts the Socket API and the Transport Services
API, but in the paragraph starting with "For example, an application first
issues a call to receive new data from the connection.", it is unclear under
which paradigm you are meaning. I'd suggest: "For example, when using the
Transport Services API, an application first ..."

[Taps] Warren Kumari's No Objection on draft-ietf… Warren Kumari via Datatracker