[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Chargeable-User-Identity
Alan DeKok [mailto://aland@deployingradius.com] writes:
> Glen Zorn wrote:
> > What is being "protected" seem not to be so much the _idea_ of data-
> driven
> > dictionaries but the existing, simplistic _implementations_
> thereof...
>
> Let's look at the statistics. For the dictionaries I have:
>
> attributes: 4294
> integer 2045
> text 1606
> ipaddr 278
> string 259
> byte 40 (unsigned 8-bit integer)
> date 30
> ipv6addr 15
> short 14 (unsigned 16-bit integer)
> ascend filter 6 (Ascend)
> ipv4/ipv6addr 5 (ipv4 or ipv6 address)
> ifid 4
> ipv6prefix 3
> signed 1 (signed 32-bit int)
>
> 13 data types in wide use, of which 5 are vendor extensions.
>
> The "complex" attributes have all been lumped together into the
> "string" category. All together, they account for about 6% of
> attributes.
>
> This means that about 95% of the attributes in wide use follow the
> RADIUS data model, as described in the guidelines document.
>
> That's good evidence that the data model is not only in wide use, but
> that it is widely useful.
What does this have to do with whether or not "complex" attributes can be
handled by a dictionary-based server?
>
> > If, after 9+ years of the existence of so-called "complex"
> attributes, your
> > programmers haven't managed to create a simple data-driven machine to
> parse
> > them, maybe you need new programmers...
>
> The design guidelines is opposed to the *gratuitous* use of complex
> types. Such use indicates that you've hired people who prefer complex
> solutions to simple ones.
I'm unaware of any technical usage for the word "gratuitous"; it seems most
useful in the context of a value judgment. Aside from that, your response
seems to be (again) utterly disconnected from my assertion.
--
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/>