Gen-ART review of draft-ietf-radext-filter-06.txt

[Suresh Krishnan <suresh.krishnan at ericsson.com>]

I am the assigned Gen-ART reviewer for
draft-ietf-radext-filter-06.txt

For background on Gen-ART, please see the FAQ at
<http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html>.

Please resolve these comments along with any other Last Call comments
you may receive.

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."



_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf