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

[Miles Fidelman <[e-mail]>]

It strikes me that the three most noticeable digressions from IETF are the IEEE 802 standards, W3C, and WHATWG.

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=[e-mail]>
Sent: Wednesday, January 14, 2026 4:32 PM
To: Bob Hinden <[e-mail]>
Cc: IETF-Discussion <[e-mail]>
Subject: Re: Is IETF is being shunned for new protocol development?

On Wed, Jan 14, 2026 at 1:00 PM Bob Hinden <[e-mail]> wrote:
>
> Hi,
>
> > On Jan 14, 2026, at 12:06 PM, Brian E Carpenter <[e-mail]> 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>
>