Glen Zorn said:
"This "all a matter of implementation" stuff is just a cop-out: thisdocument
needs to clearly specify all the entities involved, howeverskeletal that
specification may be: if the RADIUS server gets thelocation information from
another server which subsequently validatesthe response, that's fine. If the
RADIUS server does it, that's fine; Idon't really care but 'fuzziness' has no
place in standards, IMHO."
[BA] I would agree. My assumption had been that theRADIUS server was merely
looking for the presence/absence ofattributes 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 whichappear to imply
something more than this - such as the abilityof 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 nosuch
thing as 'too late to make a change'. The following text appearsin every
single I-D published: "Internet-Drafts are draft documentsvalid for a maximum
of six months and may be updated, replaced, orobsoleted by other documents at
any time." Seems pretty clear to me.I'm sure that someone will mention at this
point that 3GPP87 or somesuch has already implemented this draft; fortunately,
this is prettymuch taken care of by the next sentence (that also appears in
everysingle I-D): "It is inappropriate to use Internet-Drafts as
referencematerial or to cite them other than as "work in progress."
[BA] In this particular case there is ambiguity, so that it is notclear what
the current document is actually requiring. Assumingthat is cleared up, we can
then address the issue of what changesare 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 designpractices until
they have an RFC number?"
[BA] Since this document was developed alongside the Design Guidelinesdocument,
and the Guidelines were developed in part in response toissues raised by this
document, it is hard to argue that it shouldbe exempt, regardless of the state
of the Design Guidelines document.
_______________________________________________
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
