RE: Fixes Issue: Interim-Accounting-Interval and Local Configuration

["Nagi Reddy Jonnala \(njonnala\)" <njonnala@cisco.com>]

This is really a valid question that one comes across many times and I
also support Bernard's view point here. I would like to add the below as
well.

RFC-2869 text:

"It is also possible to statically configure an interim value on the
   NAS itself. Note that a locally configured value on the NAS MUST
   override the value found in an Access-Accept.

   This scheme does not break backward interoperability since a RADIUS
   server not supporting this extension will simply not add the new
   Attribute. NASes not supporting this extension will ignore the
   Attribute."

I'm not sure if the wording "NAS MUST override the value found in
Access-Accept" exists in the view of not to break backward 
Compatibility.

I don't think there would be any backward compatibility issues
if the NAS honors the Radius server interim interval request
(assuming that it can honor based on some locally configured
value like minimum Interim interval).

IMO, it is worth documenting it somewhere.

Regards
Nagi.



-----Original Message-----
From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org]
On Behalf Of Murtaza Chiba (mchiba)
Sent: Friday, July 15, 2005 1:53 AM
To: Barney Wolff
Cc: Bernard Aboba; radiusext@ops.ietf.org
Subject: Re: Fixes Issue: Interim-Accounting-Interval and Local
Configuration

Barney Wolff wrote:
> On Thu, Jul 14, 2005 at 10:05:32AM -0700, Bernard Aboba wrote:
> 
>>The Interim Accounting Interval is often set in order to ensure 
>>against loss of income by billing systems.  So I can understand why 
>>there is concern if an Interim-Accounting-Interval attribute sent by a

>>RADIUS server would be ignored by the NAS.
>>
>>Although I do not recall the conversations that lead to this paragraph

>>being inserted, I think the concern may relate to inappropriately 
>>small values being sent by a RADIUS server.  For example, if the 
>>implementation has a setting for "minimum Interim-Accounting-Interval"

>>then I would say that this should not be overridden by a smaller 
>>value, but could be overridden by a larger one.
> 
> 
> I think the issue is whose policy shall apply, when the RADIUS server 
> and NAS are under different administrative control.  Setting the value

> in the NAS is the equivalent of overriding whatever value is set by 
> the server in the proxy that (presumably) should exist between the NAS

> and the server in this case.
> 

Thats an interesting point.  In wholesale environments sometimes the
wholesaler wants to control specific config bits such as compression,
for instance.  For compression it would be undesireable for a retailer
to turn it on for users as it significantly degrades the performance and
hence would affect subscribers for other retailers as well.

In this case too a smaller interim value would presumably chew up more
resources, so I agree with Bernard that retailers should be able to
change the interval time on a per user basis as long as they are not
increasing the frequency of updates beyond a configured threshold.


Murtaza

> 
>>However, if the nature of the implementation setting is "use value X 
>>by default, but allow the RADIUS server to override it" I don't 
>>understand why that should be prohibited.
> 
> 
> One can always speculate on why values would be configured directly in

> the NAS if the proxy is under the same administration.  Perhaps the 
> thinking was that some NASes may be intelligent enough to pick the 
> right server based on NAI or other info without an intervening proxy.

> In that case configuration of values on the NAS is the equivalent of 
> doing so in a virtual proxy, and, since a proxy can always override 
> attribute values, the NAS settings win.
> 
> A definite choice, even if "wrong", is probably better than 
> uncertainty in cases like this.
> 
> Regards,
> Barney
> 
> --
> 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/>

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

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