Glen Zorn writes...
There's just one big difference: EAP is, in fact, a separate protocol,
distinct from RADIUS.
We're talking about EAP messages tunneled in RADIUS Attributes. That's what
qualifies for the "opaque blob" exception.
We're talking about RADIUS attributes here, and the document states that
the RADIUS server bases a decision upon these attributes.
Yes, I tend to agree with you. The consensus position, as I understand it,
is that these are "semi-opaque blobs" because the contents are derived from
a separate protocol (a DHCP option, I think, but I may be mistaken).
There isn't anything I can find in the draft that even suggests the
existence of some "plug-in".
Nor would I expect you to. That would be one of those infamous
"implementation specific details".
Very little about the operation of a RADIUS server has to do with the
on-the-wire protocol.
Eh?
This "all a matter of implementation" stuff is just a cop-out: this
document needs to clearly specify all the entities involved, however
skeletal that specification may be: if the RADIUS server gets the
location information from another server which subsequently validates
the response, that's fine. If the RADIUS server does it, that's fine; I
don't really care but 'fuzziness' has no place in standards, IMHO.
The "fuzziness" I was talking about was the applicability of the "opaque
blob" exception in the RADIUS Attribute Design Guidelines. It is claimed to
apply in this case, and I, like you, don't quite buy it. However, the
consensus position of the GEOPRIV and RADEXT WGs (from WGLC) is that it does
apply.
So are you saying that good design practices aren't good design
practices until they have an RFC number?
No. I'm simply saying that two dissenting opinions do not a rough consensus
break. :-)
_______________________________________________
IETF mailing list
IETF(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf