RE: Issue 111: Accounting

["Greg Weber \(gdweber\)" <gdweber@cisco.com>]

Mauricio,
A couple questions inline at GDW> 

> -----Original Message-----
> From: owner-radiusext@ops.ietf.org 
> [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Sanchez, 
> Mauricio (PNB Roseville)
> Sent: Wednesday, February 01, 2006 7:50 PM
> To: Bernard Aboba; radiusext@ops.ietf.org
> Subject: RE: Issue 111: Accounting
> 
> 
> Bernard noted a while back... 
> 
> > -----Original Message-----
> > From: owner-radiusext@ops.ietf.org 
> > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba
> > Sent: Sunday, November 13, 2005 10:17 PM
> > To: radiusext@ops.ietf.org
> > Subject: Re: Issue 111: Accounting
> > 
> > Here is what RFC 2866 says about the notion of an 
> Accounting Session:
> > 
> <...removed what RFC2866 says about accounting...>
> > 
> > As Greg noted, the Service-Type is not being changed here, so 
> > that the Service is continuing, and sending of additional 
> > Start/Stop messages is somewhat odd.  Also, do we really want 
> > individual RADIUS attributes to provide their own definitions 
> > of when a new session is started and stopped?  
> > RADIUS accounting is a separate protocol from RADIUS 
> > authentication, and runs on a separate port.  Authentication 
> > attributes that affect accounting (Class, 
> > Acct-Interim-Interval) have to date been general ones.  
> > Terminating the Accounting Session in mid-stream could cause 
> > issues with RADIUS implementations that use the Accounting 
> > Records for things like simultaneous usage control.
> > 
> > Paul Congdon said:
> > 
> > At IETF-64 we reviewed this issue.  There did not seem to be 
> > any objection to having compliance statements in the Annex 
> > given that this Annex is where the context for the statements 
> > is developed.  Also, since a new session is created, as 
> > stated in the draft, there is no need to use INTERM messages.
> > 
> > --------------------------------------------------------------
> > -------------------
> > Issue 111: Accounting
> > Submitter name: Greg Weber
> > Submitter email address: gdweber@cisco.com Date first 
> > submitted: August 10, 2005
> > Reference: http://ops.ietf.org/lists/radiusext/2005/msg00636.html
> > Document: IEEE802-00
> > Comment type: T
> > Priority: S
> > Section: A.3
> > Rationale/Explanation of issue:
> > 
> > The accounting requirements do not seem to be fully treated 
> > by the draft.  Section A.3 has a MUST requirement related to 
> > accounting.  I would think that MUST requirements should be 
> > treated by the text, not in an appendix.  Why does 
> > redirection require a STOP/START pair?  Can't this 
> > information be conveyed via an INTERIM record for the same 
> > session?  If the Service- Type is not changing, I'd think 
> > that an INTERIM would suffice.
> 
> In light that the treatment of accounting behavior would be 
> best treated elsewhere, such as in 3576bis, I would suggest 

GDW> What happens if I have an HTTP redirect rule with 
redir-cnt set to 10, and I send this rule in an
Access-Accept (i.e. no CoA in the picture).  Wouldn't it
be useful to get an Accounting-Request when the redirection
is removed (redir-cnt goes to zero)?  Assuming that situation
is not described in 3576bis, where would it be described?

> that we omit any discussion of accounting behavior in this 
> draft.  This means that sections 1.4 would be modified and 
> section A.3 would be eliminated to remove accounting
> references. 

GDW> Would section 3, including the Acct-NAS-Traffic-Rule 
attribute, also be removed?

Greg
> 
> Does this seem like a reasonable path?
> 
> Cheers,
> MS
>  
> 
> --
> 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/>