Glen Zorn writes...
As a result, the introduction of new complex data types within
RADIUS attribute specifications SHOULD be avoided, except
in the case of complex attributes involving authentication or
security functionality.
All of the attributes are security related.
Yeah. I've always been a bit uncomfortable with the "security functionality"
escape clause in the RADIUS Design Guidelines draft. Lots of things can
reasonably be claimed to be "security related". I would have preferred the
exception to be crafted a bit narrower, just for this reason. But, unless
wording of Design Guidelines is changed, you have a legitimate argument.
I do not see any pressing need to make this attribute carry seven
independent fields. The RADIUS attribute space has sufficient room to
allocate 7 attributes. If the extended attribute format is used, then
nearly all space limitations are removed. I would recommend that these
independent values be split up into independent attributes that follow
the RADIUS data model.
Given that there are already multiple interoperable implementations and all
of the attributes are security related, I see no pressing need to make
people change running code to satisfy your personal preferences. Sorry if
these attributes were designed to be easy to implement for people writing
PKM code, rather than RADIUS code.
No one has ever claimed that following the RADIUS Design Guidelines is the only
way to interoperable implementations. Lots of designs, good, bad and
indifferent, can be made to interoperate .
If we are to dismiss the Design Guidelines as a "personal preference" how
are they to be taken seriously? I understand that following someone else's
design guidance is not always popular with developers, but following regular
design patterns is a well recognized practice in software engineering, that is
generally attributed with increasing product quality and maintainability. I
think we simply need to "get with the program" here.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf