Draft:  draft-ietf-radext-filter-06.txt
Reviewer: 
Review Date:
IETF LC Date:

Summary: This draft is basically ready for publication, but has minor 
issues that need to be clarified before publication.

Comments:

Substantial
===========

* Section 6

"  A legacy NAS not compliant
    with this specification may silently discard the NAS-Filter-Rule
    attribute while permitting the user to access the network.  This can
    lead to users improperly receiving unfiltered access to the network.
    As a result, the NAS-Filter-Rule attribute SHOULD only be sent to a
    NAS that is known to support it."

I do not understand the rationale behind this. In this case, if the 
server sends the NAS-Filter-Rule (that is ignored by the NAS) it is no 
worse off than not sending it at all. In either case the user gets 
unfiltered access to the network. Is this recommendation really necessary?

Minor
=====
* Section 2
  " Given the absence in [RFC4005] of well-defined precedence rules for
    combining Filter-Id and NAS-Filter-Rule attributes into a single
    rule set, the behavior of NASes receiving both attributes is
    undefined, and therefore a RADIUS server implementation cannot
    assume a consistent behavior"

I do not understand why the lack of clarity in the Diameter spec 
precludes this document from coming up with its own precedence rules.
e.g. The document may state

"If a Filter-Id attribute is present, a
  NAS implementing this specification MUST silently discard
  NAS-Filter-Rule attributes, if present."

I do not have a strong opinion about this but I feel that the reasoning 
is not obvious.

* Section 3

The following legend is unnecessary since it is not used in any message type

"     0-1   Zero or one instance of this attribute MAY be
            present in the packet."

Editorial:
==========

* The document contains no form feeds

* Some pages are longer than 58 lines

* Introduction paragraph 2

This sentence does not read well

"However, in situations where the server
  operator does not know which filters have been pre-populated, it
  useful to specify filter rules explicitly."

Perhaps add a "is"/"will be"/"may be"... before the word useful.

"However, in situations where the server
  operator does not know which filters have been pre-populated, it
  is useful to specify filter rules explicitly."