During the BOF Subtypes came up again (cause I brought up the issue)
The reason that I brought up the issue was because there were several Drafts
that were using Subtypes.
In one of the drafts that I was contributing, an attribute of type string
contained sub-attributes that were encodes as attribute value pairs. Having
a RADIUS server decode this type of attribute is a sure way to kill RADIUS
performance.
Looking at the drafts, the reasons folks are using subtypes is to group
attributes that only make sense together. For example zipcode,
streetAddress, etc in a LocationAttribute. Or a bunch of attributes that
reflect HTTP Digest authentication.
We either disallow all subtypes period end!!! Or permit them providing they
meet a certain set of criteria.
To disallow them outright would be a problem because some of these drafts
are already being used and some have been standerdized by other SDOs.
The criteria to use would be something along the line:
Subtypes should follow TLV encoding. This would allow RADIUS Servers to use
the same code they already use to parse existing attributes. This would
also follow subtype encoding within VSAs. TLV is what is being used most
often when folks subtype.
You only subtype attributes that belong together. Typically they are going
to be interpreted by the NAS and the RADIUS server. Proxy's should not have
to parse the subtypes.
Comments?
--
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/>