[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Issue 114: WGLC Review (traffic-rule-draft)



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