Per IETF-68 resending email where discussion went cold. See below. Resolution proposed in original email. MS -----Original Message----- From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Sanchez, Mauricio (PNB Roseville) Sent: Tuesday, January 10, 2006 8:44 AM To: Bernard Aboba; radiusext@ops.ietf.org Subject: RE: Issue 114: WGLC Review Bernard submitted a while back... > -----Original Message----- > From: owner-radiusext@ops.ietf.org > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba > Subject: Issue 114: WGLC Review > > I do not understand the purpose of the accounting > functionality in the draft. > > The focus of this document is VLAN attribute, priority and > filtering. How does Acct-EAP-Auth-Method fit into that? I > think this is a leftover WLAN attribute which should be removed. [ms] Agree. This was a vestiage from earlier days of document and was left in error. > > Acct-NAS-Filter-Rule attribute. The purpose of this attribute > is to keep count of hits on filter rules. This duplicates > functionality under development in other WGs such as IPFIX, > and so I'd question whether this is appropriate functionality > for RADIUS accounting. [ms] I see this accounting attribute as adding basic audit capability to the authorization policy expressed through the NAS-Filter-Rule attribute. Surely you would agree that performing accounting/audit functions is well within scope of RADIUS. Accounting records already have data counts for session use, so why not have filter hit counts along with them? A straightforward use case is an administrator that has a (strict) filter policy for which he/she wishes to be notified anytime a user tries to pass unauthorized traffic through the NAS. Errant users could then be sanctioned in the future. > > Overview > > I do not understand the purpose of Section 2, Overview. Most > of it seems like it could be deleted without losing anything. [ms] Other than the first paragraph, most of the material comes by way of the old redirect draft Avi was stewarding. If he has no objection, we can see about removing text from this section. 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/>
Attachment:
smime.p7s
Description: S/MIME cryptographic signature