Request - Modification to Status Server to have Clients Stats in separate VSAs

[Alan DeKok]

Peter Lambrechtsen wrote:
> I'm currently playing around with the Status Server for stats
> gathering and was hoping to have a minor change in the interface to
> support extracting the Client information under different VSAs rather
> than reusing the current "FreeRADIUS-Total-*" VSAs. It's not
> particularly logical in my view to have the same VSA returned twice in
> a Access-Accept, and then needing to determine if it's the client
> related one or the global server related one by it's sequence in the
> payload. It would make more sense in my mind to have the Client stats
> as separate VSAs.

  They should be separate VSAs.  I'm not sure what crack I was smoking
when I cam up with the current VSAs, but oh well.

  My inclination now is to leverage RFC 6929 and the extended
attributes, and TLVs.  We could create VSAs which mirror the SNMP
information in RFC 4668..4671.

  Or, we could create our own TLVs in a sane format.  e.g. have a
"parent" TLV for home server, client, and "this" server.  Inside of that
parent, have the *same* list of child TLVs, in the same order, with the
same meaning.

  I'm inclined to leave 2.x the way it is.  It's imperfect, but it's
workable.  The new 3.0 code is preferred for new functionality.

  The nice thing about the 3.0 code is that if you're using the 3.0
radclient, you don't really care that the counters are buried inside of
TLVs.  They come out in "attr = value" form, just like anything else.

  Alan DeKok.