[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/>