Issue: WGLC comments on draft-ietf-radext-ieee802-00.txt

["Greg Weber \(gdweber\)" <gdweber@cisco.com>]

Description of issue: WGLC comments on draft-ietf-radext-ieee802-00.txt
Submitter name: Greg Weber
Submitter email address: gdweber@cisco.com
Date first submitted: 8/10/05
Reference: N/A
Document: draft-ietf-radext-ieee802-00.txt
Comment type: T/E
Priority: S
Section: various
Rationale/Explanation of issue:


1) Compliance vs. Functional Coherence
Most of the RADIUS RFCs tend to address a single functional
area, e.g. IPv6 attributes, EAP, tunneling, etc.  This is
good because RFCs tend to become checkmarks on RFPs or
customer requirements.  This documents seems to combine
functionality that is only related to IEEE 802 (VLANs) and
things that are independent of access type.  For example,
filtering and redirection can apply equally usefully to
PPP-based L2 connections.  If I'm a vendor of PPPoA-based
DSL termination NASes, I can't claim compliance to this
potential RFC unless I support all the VLAN oriented 
attributes because the compliance language in section 1.2
requires an all or nothing approach to compliance.  Can 
the authors clarify why the NAS-Filter-Rule/QoS-Filter-Rule
attributes are combined with the 802 specific attributes?
I would think these should be addressed via separate documents.

2) Compliance vs. Optional Functionality
I did not understand how the "options" in section 3.5 relate
to the compliance language in section 1.2.  If I do not 
support the "Cnt" option for counting rule hits, can I still
claim compliance with this document?  Are these optionally
specified or optionally supported?

3) Accounting
The accounting requirements do not seem to be fully treated
by the draft.  Section A.3 has a MUST requirement related to
accounting.  I would think that MUST requirements should be
treated by the text, not in an appendix.  Why does redirection
require a STOP/START pair?  Can't this information be conveyed
via an INTERIM record for the same session?  If the Service-
Type is not changing, I'd think that an INTERIM would suffice.

4) NAS-Filter-Rule proto specification
I could not understand some parts of the specification; I 
guess Pasi has already commented on this.  In particular, the
proto spec:
  proto  <l2:<ether2[:val]|rmon_str>> type[:val]|ipprot|ip|http>
there are not an equal number of "<" and ">" and the 
"type[:val]" part is not described.  The "ipprot" does not
provide for a value part.

5) Attribute concatenation
I didn't understand how the language in section 3.6 about
concatenating QoS-Filter-Rule(s) works.  If these are simply
concatenated, how does an implementation distinguish between
multiple 'small' QoS-Filter-Rules and a single larger 
attribute?  What if I want to send one QoS-Filter-Rule which
spans 253, followed by one which does not?

Greg





--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>