Hi Alan, Thanks for your help. I’ve marked this as HFDU.
Regards, Rob From: radext <[email protected]> on behalf of Alan DeKok <[email protected]> Date: Monday, 15 January 2024 at 14:20 To: Rob Wilton (rwilton) <[email protected]> Cc: RFC Errata System <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>, Paul Wouters <[email protected]> Subject: Re: [radext] [OPSAWG] [Technical Errata Reported] RFC2865 (6915) On Jan 15, 2024, at 7:14 AM, Rob Wilton (rwilton) <[email protected]> wrote: > Hi RFC 2865 authors, OPSAWG, I've CC'd RADEXT, as that WG is currently active. I've also removed the 2865 authors email addresses. I believe those became inactive decades ago. > I think that this errata may be valid, but given the age of the RADIUS > protocol, and the fact that I'm not familiar with it and this is a change to > the protocol, then I'm somewhat concerned with verifying this errata, and > hence I propose to move it to "Held for Document Update". > > Does anyone have any comments on this proposed resolution? I think "hold for document update" is best. We've covered these issues in RFC 8044, which defines data types for RADIUS (octets, printable text, IPs, integers, etc). There are no data types which permit zero-length values. The variable-length data types defined in Section 3.4 (printable strings) and 3.5 (binary data) both say: Strings of length zero (0) MUST NOT be sent; omit the entire attribute instead. There is no _general_ prohibition on attributes having zero length values. But it is not currently permitted to define an attribute which has a zero-length value. As such, "hold for document update" is the reasonable conclusion. Alan DeKok. _______________________________________________ radext mailing list [email protected] https://www.ietf.org/mailman/listinfo/radext
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
