Hello tsv-area, I'm co-chair of radext and the document shepherd for the above document, and it's currently awaiting its PROTO write-up.
As I went through the latest revision, it occured to me that there are quite some transport considerations in this, which are beyond my technical knowledge. In short: A protocol that previously had no fragmentation support (RADIUS over UDP, max size 4096 per datagram, max one datagram in flight, may be "routed" via RADIUS proxies in a kind of overlay network) now gets some; the fragmentation is done in a way which is "far away" from the usual way - no sequence numbers, duplicate detection is based on a randomly chosen State attribute, there is no explicit NAK for missing chunks and instead the RADIUS timeout is the only way to detect and correct fragments gone AWOL. There may be fragmentation-aware and -unaware RADIUS proxies on the path between sender and ultimate recipient of the payload. I'm thinking that this warrants a closer look by TSV experts. Am I asking at the right place? The draft is here: https://datatracker.ietf.org/doc/draft-ietf-radext-radius-fragmentation/ Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66
0x8A39DC66.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
