Alan DeKok writes...
Why is the Server-Status "query" packet responded to by an Access-Accept "reply" packet? It seems to me that were over-loading the semantics of Access-Accept by using it in this way. Maybe that's not particularly harmful -- I don't know for sure -- but over-loading always seems like a Bad Idea (tm) to me.Yes it's not ideal. It's a historical practice.
Yes, so Bernard has explained.That makes review of this document in RADEXT a little bit challenging. We can, of course, polish the prose and make sure that the descriptions are self-consistent and clear and that the organization is logical. I guess only those who have access to the "historical implementation" can discern whether the descriptions are accurate and correct.
The IESG, and the IETF at large, hold the WG, in general, and the WG Chairs and/or Document Shepherd, in particular, accountable to assert that the submitted draft meets certain protocol quality standards. Now, I suppose that the quality of protocols is somewhat subjective. Nonetheless, its uncomfortable to be held accountable for the quality of a design that you are not able to affect in any way.
Bernard raises the example of RFC 5176, which was a "bis" revision of RFC 3576. The former was not the product of any working group, AFAICT, and was not labeled as such when it was published. The RADIUS WG had closed and the RADEXT WG had not yet been conceived. I'm not sure that's an appropriate analogy.
I think that we need to be clear in publishing this draft and an RFC that the *protocol* it documents was *not* the work product of the RADEXT WG, but rather of various historic implementors. Truth in advertising. There are some hints at that already. I'll propose some more explicit text as a formal RADEXT Issue.
Wouldn't it have been possible to use the same Command Code (Server-Status) for *both* the query and response, with the context coming from who's doing the receiving? I think that would be preferable, in a number of ways.RADIUS has traditionally used separate status codes for requests and replies. Using the same code for both is about as bad (IMHO) as overloading Access-Accept.
I think you're probably right. Sigh. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/radiusext/>