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

Extended Filter attribute: Change summary from -01 to 02; Issues score card review



For those keeping track, the extended filter draft
(draft-ietf-radext-filter-rules-02.txt
) has been an active working group item for over two years in one form or
another.  At the rate it's going, we may all retire before it's complete. ;)
Anyway.

Substantive changes from version -01 to -02
-------------------------------------------
1. Removed requirement that rule types appear in a specific order by
removing text: "Furthermore, if the list contains different types of rules,
they MUST appear in the following order: flush rules, base encapsulation
tunnel rules, base encapsulation filter rules, IP tunnel rules, HTTP
redirect rules, IP filter rules, and HTTP filter rules."  (Section 2.5)

The above change address should address part of Issue 170 (Precedence and
order for NAS-filter-rule).

2. Updated attribute behavior in presence of NAS-filter-rule:
"Filter-ID (11), NAS-Filter-Rule [Filter] and NAS-Traffic-Rule attributes
define how filters are to be applied in the NAS. These attributes are not
intended to be used concurrently and          SHOULD NOT appear in the same
RADIUS message. Only one type of filtering attribute must be processed. If a
Filter-ID (11) is present, then the NAS-Traffic-Rule MUST be ignored, if
present." (Section 2.5)

3. Added a version label prefix to rule syntax.  Each rule now includes a
"v1" prefix designating the rule as conforming to version 1 of traffic-rule
syntax.  The idea here is to allow future updates/changes to the rule syntax
without having to define another attribute and burn another type number.  

4. Re-did the Diameter Considerations section [5].  Now are using the same
approach employed by rfc4675 (RADIUS attributes for virtual LAN and priority
support).  The approach eliminates the need to re-create a diameter-specific
version of nas-traffic-rule and rather relies on the general
radius<->diameter interoperability mechanisms.  I do have a question as to
whether the diameter value type specified (OctetString) is the right one or
not.  I'm no diameter value type expert, so feedback welcome. 

Issues scorecard
---------------
According to extended RADEXT website, the draft has the following issues
filed against it:

1. Issue 111: Accounting (submitted by Greg W.)
I believe this issue is no longer relevant since the sections in question
are no longer present. Next step: close out on website.

2. Issue 114: WGLC Review (submitted by Bernard A.)
Various sub-issues under this issue.  All but one sub-issue are closed.
Remaining sub-issue is on why rule hit accounting is present in the draft.
Next step: discuss this week.

3. Issue 115: WG Last Call Comments (submitted by Dave N.)
Various sub-issues under this issue.  I believe the only remaining sub-issue
open is about moving the section 1.3 (Attribute Interpretation) into the
security section.  Didn't understand why back then and I still don't
understand.  Next step:  discuss this week.

4. Issue 130: Diameter Compatibility (submitted by Bernard A.)
Given the overhaul of section 5, this one may be finally solved. Next step:
Bernard to approve/disapprove section 5

5. Issue 164: Review (submitted by Jari A.)
Various sub-issues under this issue.  I don't believe there are any
unresolved sub-issue left, but Jari needs to confirm/refute my stance.  Next
step: Jari to review whether all his comments have been addressed.

6. Issue 169: Handing unparsable nas-filter-rule (submitted by Greg W.)
I believe Greg's issue have been dealt with.  Next step: Greg to review
whether his comment have been addressed.

7. Issue 170:  Precedence and order for NAS-filter-rule (submitted Greg W.)
Last discussion on this one was in June '06.  Unsure whether draft -02
continues or deals with the various sub-issues discussed on the email list
thus far.  Next step:  Review of draft -02 to see whether sub-issues still
exist.

8. Issue 192: Comments (Submitted by Jouni K.)
Last discussion on this was back on Nov. 10, 2006.  Jouni agreed with many
of the changes in -01 that address his comments.  Next step: I'm going to
reply to Jouni's email on remaining open comments. 

Cheers,
MS

--------------------------------------------
Mauricio Sanchez, CISSP
Network Security Architect
ProCurve Networking Business
Hewlett Packard
8000 Foothills Boulevard, ms 5557
Roseville CA, 95747-5557

916.785.1910 Tel
916.785.1815 Fax
mauricio.sanchez@hp.com
--------------------------------------------   

Attachment: smime.p7s
Description: S/MIME cryptographic signature