RADIUS Filter Rule Attribute
draft-ietf-radext-filter-08

[Ballot comment]
From the SecDir Review by Sam Weiler:

  These concerns may stem, in part, from the document's brevity and
  propensity to cite other docs -- as someone not steeped in RADIUS and
  Diameter lore, I found it a bit hard to decipher.  The table in
  section 3, for instance, seems like it must be there to mirror some
  table in other specs.  Plainer language throughout might be helpful.

[Ballot discuss]
It is clear that the integrity protection of the filter list is
  beyond the scope of this document.  However, I do think that the
  security considerations ought to say something about the impact if
  that protection is not provided.  What are the consequences of a
  modification to the filter list.  Consider adding entries, removing
  entries and altering entries.

[Ballot discuss]
Review comment from Glen Zorn:

The use of DIAMETER_INVALID_AVP_LENGTH as an indication that
the Diameter NAS-Filter-Rule AVP could not be translated into a RADIUS
NAS-Filter-Rule Attribute is questionable at best.  The semantics of the
Diameter error code are that the AVP length is invalid _in Diameter_,
but this is not the case here.  A new error code indicating the actual
error encountered (e.g., DIAMETER_RADIUS_AVP_UNTRANSLATABLE or some such
would be far preferable.

[Ballot discuss]
Review comment from Glen Zorn:

Quickly, the use of DIAMETER_INVALID_AVP_LENGTH as an indication that
the Diameter NAS-Filter-Rule AVP could not be translated into a RADIUS
NAS-Filter-Rule Attribute is questionable at best.  The semantics of the
Diameter error code are that the AVP length is invalid _in Diameter_,
but this is not the case here.  A new error code indicating the actual
error encountered (e.g., DIAMETER_RADIUS_AVP_UNTRANSLATABLE or some such
would be far preferable.

IANA Last Call Comment:

Upon approval of this document, the IANA will make a single
change to the registry located at:

http://www.iana.org/assignments/radius-types

In the subregistry called "RADIUS Attribute Types" a single
value will be added:

Value Description
-------- ----------------
TBD NAS-Filter-Rule

We understand the above to be the only IANA Action for
this document.

Title:  RADIUS Filter Rule Attribute                                           
I-D:                                                                           
http://www.ietf.org/internet-drafts/draft-ietf-radext-filter-06.txt           
                                                                               
Status: Proposed Standard                                                     
                                                                               
Response to template:                                                         
                                                                               
1) Have the chairs personally reviewed this version of the ID and do           
  they believe this ID is sufficiently baked to forward to the IESG           
  for publication?                                                           
                                                                               
Yes.                                                                           
                                                                               
2) Has the document had adequate review from both key WG members and           
  key non-WG members? Do you have any concerns about the depth or             
  breadth of the reviews that have been performed?                           
                                                                               
Yes. The ID has had 2 working group last calls.                               
                                               
3) Do you have concerns that the document needs more review from a             
  particular (broader) perspective (e.g., security, operational               
  complexity, someone familiar with AAA, etc.)?                               
                                                                               
No concerns.  The document is based on an AVP defined in RFC 4005, and a       
                                                                               
filter rule syntax defined in RFC 3588, so it has been reviewed in other       
                                                                               
contexts as well as within the RADEXT working group,                           
                                                                               
4) Do you have any specific concerns/issues with this document that           
  you believe the ADs and/or IESG should be aware of? For example,           
  perhaps you are uncomfortable with certain parts of the document,           
  or whether there really is a need for it, etc., but at the same             
  time these issues have been discussed in the WG and the WG has             
  indicated it wishes to advance the document anyway.                         
                                                                               
No.

5) How solid is the WG consensus behind this document?  Does it               
  represent the strong concurrence of a few individuals, with others         
  being silent, or does the WG as a whole understand and agree with           
  it?                                                                         
                                                                               
There is solid consensus behind this document.  6 people responded to         
WG last call.  The issues raised, available for inspection at                 
http://www.drizzle.com/~aboba/RADEXT/, were resolved in the -06               
version of the document.                                                       
                                                                               
6) Has anyone threatened an appeal or otherwise indicated extreme             
  discontent?  If so, please summarize what are they upset about.             
                                                                               
No.                                                                           
                                                                               
7) Have the chairs verified that the document adheres to _all_ of the         
  ID nits?  (see http://www.ietf.org/ID-nits.html).                           
                                                                               
Yes. An output of the run on this revision of the ID by the online nits       
checker:

idnits 1.120                                                                   
                                                                               
tmp/draft-ietf-radext-filter-06.txt:                                           
                                                                               
  Checking nits according to http://www.ietf.org/ID-Checklist.html:           
                                                                               
    Checking conformance with RFC 3978/3979 boilerplate...                     
                                                                               
    the boilerplate looks good.                                               
                                                                               
    No nits found.                                                             
                                                                               
  Checking nits according to                                                   
http://www.ietf.org/ietf/1id-guidelines.txt:                                   
  - The page length should not exceed 58 lines per page, but there was 9       
    longer pages, the longest (page 2) being 60 lines                         
  - It seems as if not all pages are separated by form feeds - found 0         
form                                                                           
    feeds but 10 pages                                                         
           
  Miscellaneous warnings:                                                     
    None.                                                                     
                                                                               
  Experimental warnings:                                                       
    None.                                                                     
                                                                               
    No nits found.                                                             
                                                                               
8) Does the document a) split references into normative/informative,           
  and b) are there normative references to IDs, where the IDs are not         
  also ready for advancement or are otherwise in an unclear state?           
  (Note: the RFC editor will not publish an RFC with normative               
  references to IDs, it will delay publication until all such IDs are         
  also ready for publication as RFCs.)                                       
                                                                               
The document does split references into normative and informative ones.       
There are no normative references to IDs.                                     
                                                                               
9) For Standards Track and BCP documents, the IESG approval                   
  announcement includes a writeup section with the following                 
  sections:   

  - Technical Summary                                                         
                                                                               
  While RFC 2865 defines the Filter-Id attribute, this requires that         
  the Network Access Server (NAS) be pre-populated with the desired           
  filters.  However, in situations where the server operator does not         
  know which filters have been pre-populated, it useful to specify           
  filter rules explicitly.  This document defines the NAS-Filter-Rule         
  attribute within the Remote Authentication Dial In User Service             
  (RADIUS).  This attribute is based on the Diameter NAS-Filter-Rule         
  Attribute Value Pair (AVP) described in RFC 4005, and the                   
  IPFilterRule syntax defined in RFC 3588.                                   
                                                                               
  - Working Group Summary                                                     
                                                                               
There have been 2 WGLCs on the document, the initial one was                   
part of the IEEE 802 attributes document, and the last one as                 
a standalone document.  Discussion on the document related largely             
to the mechanism by which filter rules would be split across multiple         
attributes and how a NAS should handle different filter attributes (e.g.       
         
Filter-Id + NAS-Filter-Rule) included in a single Access-Accept.