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(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf