[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RADIUS FIXES] Authorize Only
"Avi Lior" <avi@bridgewatersystems.com> wrote:
> I think perhaps we should explore the danger of having such a
> facility and perhaps describe how it is to be used.
Your application seems to be well-scoped, at least.
> This is a good question. I think the "application" should define the
> semantics. So if the Application is Base RADIUS (2865 etc) then we
> follow the rules specified by 3576 that new attribute replace previously
> received attributes. In the case of Prepaid the application deals with
> this explicitly so that there is no confusion.
It is then a "vendor-specific" value for Service-Type.
> Sure. But we should not limit something because some use-cases are going
> to be problematic. In prepaid I would have a real problem if I don't
> have this capability.
I would not want that. :)
....
> Does this answer your questions?
Yes. My suggestion is to call your scenario "pre-paid-re-authorization".
I would prefer to define a new application-specific value for
Service-Type. That value can then take on whatever meaning is
required for your needs. The re-use of Authorize-Only is awkward, and
could be deprecated. (Barring re-deployment costs.)
That being said, I have no serious objections to permitting this use
of Authorize-Only. I would still prefer to have the "issues and
fixes" strongly discourage further use of the value, though.
Alan DeKok.
--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>