Re: [Geopriv] Last Call: draft-ietf-geopriv-radius-lo (Carrying Location Objects in RADIUS and Diame

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.