Content-Type: multipart/signed;
	boundary="Apple-Mail=_0EE9EE44-645A-4D7E-86F0-FDB40B6BA2FF";
	protocol="application/pgp-signature";
	micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.700.81.1.4\))
From: Alan DeKok <alan.dekok@inkbridge.io>
In-Reply-To: 
 <178539470620.1451407.3941727183319194716@dt-datatracker-d4d6ff9d9-fsx7d>
Date: Thu, 30 Jul 2026 08:05:58 -0400
Message-Id: <D877EAF2-F502-4645-B3E1-BC6EF4364059@inkbridge.io>
References: 
 <178539470620.1451407.3941727183319194716@dt-datatracker-d4d6ff9d9-fsx7d>
To: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Message-ID-Hash: 23N2AI2XGHUPHB7KZTKM5UZDYZSUZHRJ
CC: The IESG <iesg@ietf.org>, radext-chairs@ietf.org, radext@ietf.org
Precedence: list
Subject: =?utf-8?q?=5Bradext=5D_Re=3A_Gorry_Fairhurst=27s_Block_on_charter-ietf-radex?=
 =?utf-8?q?t-07-04=3A_=28with_BLOCK=29?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/radext/_6tjXfMu4tXW-JwQWL0EBoGlGoA>


--Apple-Mail=_0EE9EE44-645A-4D7E-86F0-FDB40B6BA2FF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

On Jul 30, 2026, at 2:58=E2=80=AFAM, Gorry Fairhurst via Datatracker =
<noreply@ietf.org> wrote:
> I would like to understand more about this planned deliverable:
> * RADIUS Congestion Control draft to IESG - August 2026

  The term "congestion control" here does not refer to TCP or other =
transport protocol congestion control.  It refers to application-layer =
signalling of overload, etc.

  Similar signalling is already in Diameter:  =
https://datatracker.ietf.org/doc/html/rfc7683

  We're looking to add some application-layer signalling, as RADIUS is =
currently lacking it.  If the name "congestion control" is contentious, =
we should just rename the deliverable.

The current document which may be adopted by the WG is this one:

=
https://datatracker.ietf.org/doc/draft-janfred-radext-radius-congestion-co=
ntrol/

  If you look at the content, you'll see that the document doesn't add =
congestion control to RADIUS.  Instead, it allows servers to signal that =
specific users are being abusive, and should be blocked.   So the name =
is perhaps misleading to some used to transport-layer congestion =
control.

> Of course, I'd welcome consideration of congestion control into an =
IETF
> protocol, However - This charter item needs to either specify existing =
methods,

  RADIUS has absolutely no link-layer, or application-layer signalling.  =
It was designed in 1993.

  RADIUS is a bare-bones simple UDP request / response protocol.  If a =
packet is lost, the client might retransmit.  Or not.  Or it might send =
the packet to a different server.  There is no way for the server to =
signal anything back to the client.  The server either responds to a =
request, or discards the request.

  Given the tens of millions of production devices which use RADIUS, =
there is no reasonable prospect of adding anything like congestion =
control to the base protocol.=20

> or to work with ICCRG to evaluate the safety and properties of the =
proposed new
> CC algorithm. I am not clear which is intended here. - Specification =
of a new
> CC RFC needs to be coordinated with CCWG.

  We are not defining a new transport-layer congestion-control protocol. =
 We are patching a 1993-era application protocol which has absolutely no =
signalling.  The proposal is to add a tiny bit of signalling, which is =
nowhere near what the CCWG sees as congestion control.

  I suggest that we rename the deliverable to describe what the I-D =
does.  "Add signalling in Access-Reject to allow systems to quench =
abusive users".

  Alan DeKok.


--Apple-Mail=_0EE9EE44-645A-4D7E-86F0-FDB40B6BA2FF
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEIUl02elqcIsf1zM0v3SJ0h7dTTMFAmprPiYACgkQv3SJ0h7d
TTOgNQ//WNtaQhVe4OqYHIUEOc+1XDrmepFcNP4REOArpNZVOI3Gf3PysH/5Lk0d
d6azJ94YkQno+Un3cRUBiiE2jz1Vn6wcO+bycgikyqvX1MQYp6jXNcPolTGivxn2
WIjm3XrtFQKxmijFoFgt/F93A5T2bWokJhVHDuoQMkQ0iJuns4HdZwVD3/kazevz
AMyZZ7qBOV9bcdEJVikvaCzET5r2sE7DZyewoXnwAMPB6xHDPhqBvO9GnMG6qZXW
ltBNKXqqQgmh2uLlQVA0bmOtpleNF8ZDdzeNOKkoMPHnbgKZ4zDskGIAHJNLgcZq
qnctaYUx9bA6/JKCjW8d7VF+bpsa+OndD9m7Sht5hRIWN1s9bSoHWsgu096OqeX+
Brn9PjWENTNPZ7FeimOSP7qrt7XkqmSGOm//mKLDEbZGFxoFc2mMGeQ1Bf2me1tY
ftnJsAJVStgve2nah6IoqgfmoneSoqNfyIj1abV8lYgGoMgQIY/skYvWx1YQegff
BNt4Q+fN35pY9z+6X/xOB26MfPUZE3xkhe9bDPgaZmlLImhCdtxCJ/52JbGHeGYh
V2ZFkATdNt8Pl4SrtBLU64WveBPZIHn9Tq0VqH/JUB9XNcWYuSVqxImyUF4k4B2F
8yIHohyPd1apV8Z3mFjoDCY8lht+NG4IJ6STrGqC4z5bfjIvtg8=
=VSkq
-----END PGP SIGNATURE-----

--Apple-Mail=_0EE9EE44-645A-4D7E-86F0-FDB40B6BA2FF--