Re: Is IETF is being shunned for new protocol development?

Tom Herbert <tom@herbertland.com> Wed, 14 January 2026 21:51 UTC

Return-Path: <tom@herbertland.com>
X-Original-To: ietf@mail2.ietf.org
Delivered-To: ietf@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 6F52DA7CAF96 for <ietf@mail2.ietf.org>; Wed, 14 Jan 2026 13:51:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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=herbertland.com
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 7m5Cd3ffE2uq for <ietf@mail2.ietf.org>; Wed, 14 Jan 2026 13:51:31 -0800 (PST)
Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id E3F86A7CAF8D for <ietf@ietf.org>; Wed, 14 Jan 2026 13:51:31 -0800 (PST)
Received: by mail-lj1-x22b.google.com with SMTP id 38308e7fff4ca-38304020185so2153501fa.2 for <ietf@ietf.org>; Wed, 14 Jan 2026 13:51:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland.com; s=google; t=1768427485; x=1769032285; darn=ietf.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=FO5+QkkbSJm3Bi3ED4db/Z+GYNzSyCdpUQBxW0NrNN8=; b=KUNvmKkw+kMCzghlnDl07agGMAR3IdCdfYZ6mr3aDN6jEmnWYmSkD3kQ8ZFSpaWExP rwlGFUYp6YUs0n8NYKp/dBIks2oSZ7DJ4FkAevUv8811b4zFS8fHYpcPiBehiDA4sW2i jGNdwrOh7ES5DpMvpgeG2+cu4MVL/O4gc80qsBsw+c+n4iclF8BzlA6cZE8puu9M6NMy 4AsvLu+wAKXu+j26kMr2fmcOOamVol4i4zVyL5Kd+0QR30gydk4Qqc6oKjegKxTrpkhQ 2riFUBYwLbQCb0hi8zclZIHB4aE7NVAICzD4iyDXnf5p0PyIZ7P+s9rclbt+YaRdQm0R O8sg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768427485; x=1769032285; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=FO5+QkkbSJm3Bi3ED4db/Z+GYNzSyCdpUQBxW0NrNN8=; b=RK2rm4D3hHyiH9U5N4UHvFoSsisASXDhxk8zFDQeYjsH3crEVxa0AkED5n21ESteRz V4GC5c3zp1lKGpvDMAOyTSUqq6DmoNIhgt7DvoENLhniJPY8/MCuS+W47kOCFbLZm7+9 eU+zYOHjj+ydS+kqmrYHrWzU6akpKteYokse6xg67ai9AcQkJzVviEaJaDIpfmUwxzzk 7kaAGv8wFM0Yhh/JrkBBP9YoE7S1YxxkDkMIIRr2rAetIquCHPuakDeEzEvVfQF/VnyK RCIl7340RQxpqiAaTuR2UHd+ZQvpsAr4q983VLudJC3cjxX6pOEmjsdId31CMc7lrf9w PXVg==
X-Forwarded-Encrypted: i=1; AJvYcCXemUSAvGrDmtFMSu8C5/Tcp7q9ztHaLfmeinTvcOSiYjzQADmk6IH12tpKhy/Tu340ikWr@ietf.org
X-Gm-Message-State: AOJu0YwZc7VV6OsRsYwBSQVLmt3lC/Wd1hNGq7jQcSaQpzYu79sJnKIU 8j++tJ74dZ6V4fdR7jPoi66CUw+oSCuq5CsSTIJv2Jw3Aj68C3Xd00JN+aCTTBK4wKnsb5sDuex L9RGvxbMB/fi3Xoue+hpAsG3yBLirkNVNH++FrnV5
X-Gm-Gg: AY/fxX78/6IL6HMvJg9s90bvDvXTjVGxXhu4+B/Vs/O2rS3jCRHFK9eYczBMc7ttbAA NZKITI8/afFITBw9wrpC2QOXC8bI6f3h1c0u94r8wOaFBTcvzn+HR2yGiTsAnoJgAlPTobymxWl gdmBR5yhJK2LTuzHBfKMM0yDdBTk311uS5xcKI9hWFiYv+8nQf36tQV481F6igQcsSJYsvS7Fu6 U74dsNchZk1uQLpzDYT1oIykdu9SZM8cxXDyQ8fy6ZTw3CyqjrrsgPyO7vfwrt5Qw9e7hqEx9k+ VIWxPZAS9lgDRJsyjOKdSkAkpnmDOvaK/qt91yPx3KC3gBcnD8LEkMpeNfA=
X-Received: by 2002:a05:651c:1502:b0:37a:75c6:b44 with SMTP id 38308e7fff4ca-38362eece9dmr11856481fa.3.1768427484749; Wed, 14 Jan 2026 13:51:24 -0800 (PST)
MIME-Version: 1.0
References: <CALx6S35B+Cu-_TbGSL3ehrEymRqKy-FLP7DARK8_fzySg1VYig@mail.gmail.com> <36b7aaef-d66c-4859-91bb-03e0d78edcb3@gmail.com> <A517EF16-F913-428E-ABC8-F17B6BC79CF5@gmail.com> <CALx6S37zvmzPfKXsMhRY-57qBJtfivvUgL1ZSh8hZVpp+6Qo1Q@mail.gmail.com> <SA1PR12MB703846849FAEE19DCD859EE7B18FA@SA1PR12MB7038.namprd12.prod.outlook.com>
In-Reply-To: <SA1PR12MB703846849FAEE19DCD859EE7B18FA@SA1PR12MB7038.namprd12.prod.outlook.com>
From: Tom Herbert <tom@herbertland.com>
Date: Wed, 14 Jan 2026 13:51:13 -0800
X-Gm-Features: AZwV_QhuK8fn7Y68ZzKSAciH3mMw4L8wGjXk0DHtiSTLj8YRZNb6bZCEEvdZfUI
Message-ID: <CALx6S349vivD_xc1-N9jO+yfn7eOMTga5WsPmc4kUTJyhtTUGg@mail.gmail.com>
Subject: Re: Is IETF is being shunned for new protocol development?
To: Miles Fidelman <mfidelman@protocoltechnologiesgroup.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Message-ID-Hash: 5LDRT5YJRTYPEY5ZW3A3OB5RAQB6W2JU
X-Message-ID-Hash: 5LDRT5YJRTYPEY5ZW3A3OB5RAQB6W2JU
X-MailFrom: tom@herbertland.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-ietf.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: Bob Hinden <bob.hinden@gmail.com>, IETF-Discussion <ietf@ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
List-Id: "IETF-Discussion. This is the most general IETF mailing list, intended for discussion of technical, procedural, operational, and other topics for which no dedicated mailing lists exist." <ietf.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/6px_QJqIHCuhjVVIfEnkeXcV60w>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Owner: <mailto:ietf-owner@ietf.org>
List-Post: <mailto:ietf@ietf.org>
List-Subscribe: <mailto:ietf-join@ietf.org>
List-Unsubscribe: <mailto:ietf-leave@ietf.org>

On Wed, Jan 14, 2026 at 1:43 PM Miles Fidelman
<mfidelman@protocoltechnologiesgroup.com> wrote:
>
>
> It strikes me that the three most noticeable digressions from IETF are the IEEE 802 standards, W3C, and WHATWG.

Hi MIles,

Take a look at UEC and OCP. They are proposing new L3-L4 protocols
that are not interoperable with IETF protocols.

Tom

>
> IEEE is understandable, given their long-standing involvement as a standards body in the electrical engineering space.  W3C, not as clear why it exists.  And WHATWG is kind of a mystery - why isn't W3C isn't the standards body for HTML.
>
> Miles
>
>
> ________________________________
> From: Tom Herbert <tom=40herbertland.com@dmarc.ietf.org>
> Sent: Wednesday, January 14, 2026 4:32 PM
> To: Bob Hinden <bob.hinden@gmail.com>
> Cc: IETF-Discussion <ietf@ietf.org>
> Subject: Re: Is IETF is being shunned for new protocol development?
>
> On Wed, Jan 14, 2026 at 1:00 PM Bob Hinden <bob.hinden@gmail.com> wrote:
> >
> > Hi,
> >
> > > On Jan 14, 2026, at 12:06 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
> > >
> > > Tom,
> > >
> > > To be honest I don't think you're wrong but I don't think there is anything new here. Twenty years or so ago I used to keep a list of other SDOs in the networking arena, until it became too boring to maintain**. Once we get above layer 4, it's always been unclear what fits into the IETF remit and what doesn't. That's why the Apps area (which is called something else at the moment) keeps getting reorganized and renamed every few years. The same is true of the Transport area but less so, which is why it gets reorganized and renamed less often.
> >
> > Similar, I don’t think there is anything new here or wrong.   There are lots of reasons why some other networking organization gets formed, but I think a lot of it is about control, paid membership, IPR, etc. that doesn’t match how the IETF works.   These groups tend to come and go, but the IETF keeps going.
>
> Bob,
>
> Let me give an example that is near and dear to your heart. Congestion
> Signalling (CSIG) is described in draft-ravi-ippm-csig-01. At each hop
> in the path the router can place congestion information in a header.
> Sounds just like a job for Hop-by-Hop options right? Except that they
> aren't using HBH, they're putting the information in VLANs even though
> VLANs aren't routable (they hack things to make it routable). CSIG is
> well deployed and supported by at least one hardware. And if the VLAN
> technique is used for CSIG then it's likely the same technique will be
> used for other cases of host to network and network to host signaling.
> IMO, Hop-by-Hop options are technically a better solution, but they're
> being avoided for non-technical reasons.
>
> Tom
>
> >
> > Bob
> >
> >
> >
> > >
> > > To say it another way, the IETF is the bottom of an inverted pyramid and that means a lot of pressure.
> > >
> > > ** I took it down some years ago, but the final version is attached.
> > > Regards/Ngā mihi
> > >   Brian Carpenter
> > >
> > > On 15-Jan-26 08:36, Tom Herbert wrote:
> > >> Hello,
> > >> FYI, I would like to share a letter I sent to IAB about a concern that
> > >> IETF may be losing relevance particularly in AI networking.
> > >> -----
> > >> Dear IAB,
> > >> I would like to bring to your attention a worrisome trend that IETF is
> > >> being shunned as the SDO for developing an standandardizing new >=L3
> > >> protocols particularly those needed for networking in AI
> > >> infrastructure which is among the hottest segments for new protocol
> > >> development.
> > >> A good example is the protocols being developed by the Ultra Ethernet
> > >> Consortium (UEC). UEC is acting as a new SDO aimed at developing scale
> > >> out networking protocols for AI and HPC infrastructure. The name is
> > >> misnomer; they are actively developing a suite of L2 to L7 protocols
> > >> including an elaborate transport protocol encapsulated in UDP to
> > >> support Remote Memory Operations.
> > >> Another example is the Open Compute Project. Back in 2024 the
> > >> Congestion Signaling draft was posted to the ippm working group.
> > >> https://www.ietf.org/archive/id/draft-ravi-ippm-csig-01.html. While
> > >> the draft has long since expired in IETF, the protocol is well
> > >> deployed at least at Google I believe and there is hardware vendor
> > >> support for the protocol. Standardization of CSIG is being done in
> > >> either OCP (or UEC), but notably not the IETF.
> > >> When I ask people  why they're not taking protocols to IETF, they give
> > >> three reasons:
> > >> 1) It takes too long for IETF to do anything
> > >> 2) The process allows for anyone at anytime to raise objections and
> > >> either bring progress to a grinding halt or sink a protocol outright
> > >> 3) IETF can be too academic and not sufficiently focused on the
> > >> realities of the real world
> > >> I have seen each of these problems first hand so I do sympathize with
> > >> those who are purposely avoiding IETF. On the other hand, I think they
> > >> are throwing the "baby out with the bathwater"  so to speak since
> > >> these alternate SDOs have yet to show better results. For instance, I
> > >> believe the UEC specification would be in much better shape had it
> > >> followed a few basic design principles that are espoused by IETF
> > >> (here's my article on the problems with UEC protocol specification
> > >> https://medium.com/@tom_84912/protocol-types-and-what-was-uec-thinking-66b525765577)
> > >> Please take this into consideration, as I do worry that IETF could
> > >> start to be left behind in the world of protocol development. I'm not
> > >> sure how the concerns can be addressed, maybe there could be something
> > >> like a streamlined standardization process for non-Internet wide
> > >> protocols like those being developed for AI infrastructure? Also, I
> > >> believe there's only one working group for AI, maybe it would make
> > >> sense to have a Working Group specifically focused on networking
> > >> protocols for AI infrastructure (I would note that OCP has completely
> > >> pivoted to be AI focussed and they drew 12,000 people on-site to their
> > >> 2025 conference-- that is mind blowing).
> > >> Thanks,
> > >> Tom
> > > <orgs.html>
> >
>