[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Draft of extensions format
On Fri, 3 Sep 2010, Alan DeKok wrote:
Peter Deacon wrote:
I am suggesting what I believe to be a small change to make the existing
draft better and more likely to be implemented in the wild.
- 16-bit Type field
- All attributes (Including TLVs and sub-attributes) have distinct
integer identities.
We had discussed this option, and decided to propose something else.
Flipping a switch in a RADIUS server to
support a new extension format is no problem. However plumbing SNMP
OIDs into existing infrastructure is a significant cost issue that is
worth the attempt to avoid if possible. For this reason I strongly
oppose the draft in its current form.
See git.freeradius.org. WiMAX VSAs with nested TLV support was added
in less than 1000 lines of code. Additional internal API changes
(mostly automated changes with a Perl script) were another ~5000 lines
of code.
Even with the TLVs there is still a unique integer identity.. IE each
wimax VSA itself is nnn not nn.nn.nn. The sub-encodings can be addressed
using the text encoding scheme that virtually everyone seems to be using
so that in terms of referencing a WIMAX attribute externally its
abstracted and treated in terms of external interfaces as an ordinary
attribute and value string no different than User-Name.
Outside of the RADIUS server there are actually no changes necessary to
reference attributes in the wimax case as I understand it.
As I mentioned the RADIUS server is just the tip of the infrastructure
iceberg. The argument you are making is akin to switching from IPv4 to
IPv6. Its easy to change software to listen on an IPv6 socket.. Its quite
a different matter entirely to change all of the supporting infrastructure.
The disruptive change is only tolerated because there exist no other
reasonable option.
With this proposal for the first time in a down-to-earth practical sense
what look like SNMP OIDs would be practically necessary to reference
ordinary ungrouped attributes using the extension types added after the
standard space was exhausted. I think this can be problematic given that
RADIUS is a mature technology if only in that its been around for longer
than I will admit to remembering.
I'm all for new features and capabilities and the changes they imply.
However we must be careful as history is riddled with evidence that
unnecessary disruption is a hindrance to adoption.
Another approach I would favor is to acquire an enterprise number for
future RADIUS attributes just treat them as VSAs and have this draft focus
entirely on the grouping problem and sub-attributes.
i.e. the data shows that the cost is relatively small.
What data? Is there a survey you can point me to? Our own first hand
knowledge paints a much different picture. I would be interested in any
data showing the cost to supporting infrastructure that you or anyone else
has compiled on the subject.
In your draft TLV is actually the same thing as Wimax VSA.
No.
When I say TLV is limited to 2^8.. I essentially mean the container
grouping object (TLV) which is the same as Wimax VSA.
No.
So I still believe I am correct in that TLV in your draft does not
provide the same fragmentation options as the wimax implementation
because the entire container is limited to 2^8 while wimax is not.
No.
You have not understood the document, or the WiMAX specs.
Can I ask how would you define a grouped VSA with multiple sub-attributes
in your draft where the total length of the entire VSA exceeds the 1-byte
type field?
Having manually coded Wimax VSAs I know how to do this in Wimax. I just
don't see a path to doing it in the current draft as written.
I welcome the suggestion of a better name. Until that happens, there
is no pre-existing "TLV" data type in RADIUS. So adding one should not
cause any confusion.
Container TLV
Envelope TLV
Grouping TLV
regards,
Peter
--
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/>