RE: Review of draft-ietf-radext-fixes-00.txt

["Nelson, David" <dnelson@enterasys.com>]

Bernard Aboba writes...

> Issues still not addressed
> ----------------------------------
> 
> This draft does not address Issues 107 and 146 on the RADEXT Issues
list:
> http://www.drizzle.com/~aboba/RADEXT/
> 
> Is there an implicit recommendation that these issues be rejected?

I don't think so.

With respect to Issue 107, there was discussion on the list, but no
apparent consensus.  My recollection of the issue at hand, from the days
when RFC 2869 was being written, was that the local NAS value for
Acct-Interim-Interval was intended as a MINIMUM value that the NAS and
its network infrastructure could tolerate in terms of the imposed CPU
and network load.  This is something of a scalability issue.  I don't
recall that there was any motivation in defining this behavior for the
NAS to over-rider the RADIUS Server provided value with a smaller (i.e.
more frequent) one, only a larger (less frequent) one.

There is the issue of whether the Issues and Fixes document ought to be
revising a MUST in RFC 2869.  If we were to attempt to provide
implementation advice in this regard, I would tend to support the notion
that the NAS MUST over-ride the server provided value of
Acct-Interim-Interval if the locally configured value is larger than the
server provide value, and SHOULD NOT over-ride it otherwise.

Is there any consensus on this position?  Does this present any
backwards compatibility issues with fielded implementations?

With respect to Issue 146, there was discussion on the list, but not
apparent consensus.  We briefly considered making some changes in this
area to the MIBs themselves during review of the IPv6 capable version of
the MIBs.  We decided against making any changes to the definition of
the counters, as this would have substantial impact on fielded
implementations.  The decision was to document the potential for
mis-interpretation, in the Issues & Fixes document.  I think we need to
do at least that.

If we can come to consensus on something else, that would be OK too.
Either way, I think some text needs to be added to the draft, and I'm
willing to craft some.  If anyone has an additional opinion on this
issue, now would be a good time to comment.



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