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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf