During the discussion of the tagging scheme proposed in draft-lourdelet,
the topic of new data types has come up.
This seems to be one of those situations where it would seem that we
are faced with choosing the lesser of 2 (or maybe 3) evils:
1. Creating a new tagging scheme, along with several new attributes;
2. Creating a complex (or opaque?) attribute to encapsulate all the items that could
potentially be sent in a router advertisement;
3. Creating a dependency on a generic, but not yet completed tagging
scheme (Extended Attributes).
Each of these choices requires new code on both the RADIUS client and server,
so that this would not appear to be a consideration.
In comparing choices number 1 and 3, the third choice seems preferable in that
it would amortize the pain of supporting new data types over a wider range of
uses.
However, it is not clear to me that either choices 1 or 3 are superior to choice 2
in terms of total effort required, particularly if the route advertisement attribute
could be engineered as an opaque (string) attribute. This would remove the need
to add code on the RADIUS server.
Am I missing any potential choices or are the choices simpler than those provided
above?
|