IETF Logo Mail Archive

[ippm] Re: [Tsv-art] Tsvart ietf last call review of draft-ietf-ippm-capacity-protocol-14

Lars Eggert <lars@eggert.org> Wed, 11 June 2025 09:21 UTC

Return-Path: <lars@eggert.org>
X-Original-To: ippm@mail2.ietf.org
Delivered-To: ippm@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id C26473393FA6; Wed, 11 Jun 2025 02:21:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=eggert.org
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OsaGsosQMsWX; Wed, 11 Jun 2025 02:21:03 -0700 (PDT)
Received: from mail.eggert.org (mail.eggert.org [91.190.195.94]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id D2D803393FA1; Wed, 11 Jun 2025 02:21:03 -0700 (PDT)
Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id 5A5A18026E; Wed, 11 Jun 2025 12:21:00 +0300 (EEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eggert.org; s=dkim; t=1749633662; h=from:subject:date:message-id:to:cc:mime-version:content-type: content-transfer-encoding:in-reply-to:references; bh=dIIGBRAGsxk/7MTCo2JKk26mU4FawYF9vgqOyow8AEo=; b=a2ml477OQI4RbPqLP/fohzScTFigMcGhRE9yNeZOl591zOo/qSH03N3PcgQ/g63z5plQye G8R8ZmwDcNPDzT7dRWc/nXklwTaOyxld9Ha+J70IK8kX2bJS+eM7RTj2nUklNSWOynLzB5 tHvfP0ClIPD/P1VDplS0x4l2ekaAPiGP45AP/FKzpXfwsZpuwND9PEta4DflhdwWhomRvj qUo46KU5bwNDSovHHmwKywlv/Wo7nBopnlsvnWnzIdhQmKOTKJFZ6fXRR5nEn/Zp6aFti7 FOgNZrsUQdDdd+J839JodW6g9oy0L9GRwxRv+ALWkkIvnb3FJ/uNPJIvSsjJZA==
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.600.51.1.1\))
From: Lars Eggert <lars@eggert.org>
In-Reply-To: <BEZP281MB200716944F1E6E0F96F45D989C75A@BEZP281MB2007.DEUP281.PROD.OUTLOOK.COM>
Date: Wed, 11 Jun 2025 12:20:59 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <8EA9DB0D-CB09-4852-B5AE-93F6A33F37B6@eggert.org>
References: <174541896750.2325768.4315175667716040232@dt-datatracker-64c5c9b5f9-hz6qg> <BEZP281MB200716944F1E6E0F96F45D989C75A@BEZP281MB2007.DEUP281.PROD.OUTLOOK.COM>
To: ruediger.geib@telekom.de
X-Mailer: Apple Mail (2.3826.600.51.1.1)
X-Last-TLS-Session-Version: TLSv1.2
Message-ID-Hash: NT44R4ESDEXTCLMTH2NT3ZWC442RCVRF
X-Message-ID-Hash: NT44R4ESDEXTCLMTH2NT3ZWC442RCVRF
X-MailFrom: lars@eggert.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-ippm.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: tsv-art@ietf.org, bew.stds@gmail.com, draft-ietf-ippm-capacity-protocol.all@ietf.org, ippm@ietf.org, last-call@ietf.org, mohamed.boucadair@orange.com
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [ippm] Re: [Tsv-art] Tsvart ietf last call review of draft-ietf-ippm-capacity-protocol-14
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/Tj52piVLYtGv9creZlqdtB-tEiI>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ippm>
List-Help: <mailto:ippm-request@ietf.org?subject=help>
List-Owner: <mailto:ippm-owner@ietf.org>
List-Post: <mailto:ippm@ietf.org>
List-Subscribe: <mailto:ippm-join@ietf.org>
List-Unsubscribe: <mailto:ippm-leave@ietf.org>

Hi,

On Jun 11, 2025, at 11:47, ruediger.geib@telekom.de wrote:
> Apart from these, Med and Lars had minor comments and nits, which should be addressed by this version too. Lars raised concerns with the term "traditional", which aren't addressed by this version.

I also said

> Major issues:
> 
> I'm kinda sad to see it's 2025 and we still invent new control protocols,
> especially over UDP. Most of the complexity in this doc is due to that. I can't
> see a requirement here that the control protocol (also) needs to run over UDP.
> Can we not simply exchange JSON blobs over HTTPS to configure the subsequent
> UDP testing flows? That should eliminate much of the complexity here, and would
> probably be more extensible as well.

I appreciate that this probably isn't actionable at this time, but I do strongly believe that building these sorts of protocols from scratch is not something we should do anymore in 2025.

Thanks,
Lars

v2.35.0 | Report a Bug | By Email | System Status