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.