|
Glen Zorn said: "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." [BA] I would agree. My assumption had been that the RADIUS server was merely looking for the presence/absence of attributes and writing location data to a backend store, so that it was not required to be "location aware". However, you have pointed out statements in the document which appear to imply something more than this - such as the ability of a RADIUS server to parse and understand location data. Given that two readers have come to such widely differing interpretations of the same text, I'd suggest that these ambiguities need to be cleared up. Glen Zorn also said this: "As I understand the development cycle of an Internet-Draft, there's no such thing as 'too late to make a change'. The following text appears in every single I-D published: "Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time." Seems pretty clear to me. I'm sure that someone will mention at this point that 3GPP87 or some such has already implemented this draft; fortunately, this is pretty much taken care of by the next sentence (that also appears in every single I-D): "It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." [BA] In this particular case there is ambiguity, so that it is not clear what the current document is actually requiring. Assuming that is cleared up, we can then address the issue of what changes are needed. I don't believe there is any "statute of limitations" on addressing ambiguities. Furthermore, Glen Zorn said this: "So are you saying that good design practices aren't good design practices until they have an RFC number?" [BA] Since this document was developed alongside the Design Guidelines document, and the Guidelines were developed in part in response to issues raised by this document, it is hard to argue that it should be exempt, regardless of the state of the Design Guidelines document. |
_______________________________________________ IETF mailing list IETF@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf