|
>In this particular case, while RFC 2866 indicates that there are no >required attributes in an Accounting-Response, it doesn't prohibit >them. > > 5.13. Table of Attributes > > The following table provides a guide to which attributes may be found > in Accounting-Request packets. No attributes should be found in > Accounting-Response packets except Proxy-State and possibly Vendor- > Specific. > > That seems pretty clear. Nothing but Proxy-State && VSA's. Yes. VSAs are allowed Presumably this would also include Extended Attributes? > > I would like to know what it *means* to have VSA's in an > > Accounting-Response. What does the NAS do with them? Log them? Ignore > > them? Change it's behavior? > > This can be used to communicate server load or pending planned downtime > information back to the NAS which then can be used in server selection > algorithms. I believe there's a commercial server in the PacketCable space > doing this (for voice gateway RADIUS clients). Also have heard some > discussion about a server being able to dynamically adjust the interim > accounting record interval by setting a VSA in the accounting response (mimicking a > Diameter feature), but I'm not sure if that's implemented by any servers. > > But it sounds like you're talking about static attribute values below. > Anyway, I don't think we should try to prohibit VSAs in accounting responses. Since this document is a BCP, not an update to RFC 2866, it can quote from existing RFCs, but shouldn't modify them. So it's ok to add an item to Section 3.3 about not including standard RADIUS attributes beyond Proxy-State in Accounting-Responses, using a quote from RFC 2866 Section 5.13 for justification. Since RFC 2866 allows VSAs, I don't think they can or should be prohibited in this document. It also probably makes sense to log an issue against the Extended Attributes document for clarification on whether they can be included in Accounting-Responses. |