Per IETF-68 discussion, sending last email where discussion went cold. This email proposes a resolution as noted below. MS -----Original Message----- From: Sanchez, Mauricio (PNB Roseville) Sent: Wednesday, February 01, 2006 4: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 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. Does this seem like a reasonable path? Cheers, MS
Attachment:
smime.p7s
Description: S/MIME cryptographic signature