-----Original Message-----
From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Lothar Reith
Sent: 17 February 2004 16:07
To: 'Avi Lior'; radiusext@ops.ietf.org
Subject: "service-key" in Lior-Draft ( Radius-Prepaid-Extension)Ladies and Gentlemen,
I would like to comment on the RADIUS-Prepaid-Extension Draft.
It contains the statement:
"The exact definition of these services is not the focus of this draft. This
definition MAY include a "service key" which can be used to
correlate prepaid requests for access to a service with the service
definition in the prepaid system."Can someone please shed some light on why the concept of "service key" is being introduced.
If I understand correctly, the whole draft is about some prepaid-server (sometimes also referred to as Quota-Server - or what is the difference between a Quota-Server and a Prepaid Server?) that MAY be part of a RADIUS Server. Okay, if the prepaid server IS part of a RADIUS server, then perhaps no issue, the Service-Key is just another Attribute but I do not understand what it is good for in this case.
In the more interesting case, where the Quota-Server (or Prepaid Server) is not part of the AAA Server, the question arises to me, if the Service-Key is not a trojan-horse that actually deprives the AAA Server from its original task of service authorization. If I understand the draft correctly, then the service-key identifies a bundle of a number of primitive services to which the user has subscribed, hence it belongs into the AAA-Server and not into the Quota Server. And by the way, watch out for the definiton of the term "service" - it is not identical to the definition of "service" in the base RADIUS RFC.
Is this service subscription information not something which architecturally belongs into the the AAA Server and not into the Prepaid-Server ?
If we start splitting user subscription data over 2 databases (RADIUS Server and Prepaid Server) things become very messy. Is it design intend of that draft that the RADIUS Server becomes "transparent" and the Prepaid-Server takes over ?
Put perhaps somebody can enlight me about the wisdom of introducing the "service key" concept into this draft (which does not seem to be included in the related 3GPP2 work on PrePaid Data Service).
I had thought, that the task of a Quota-Server is to manage Quotas, and not authorize services.
my 2 Milli-Euro...
Lothar