Issue 110: Compliance and Coherence

["Congdon, Paul T (ProCurve)" <paul.congdon@hp.com>]

Greg has made the following comment on the 802 attributes draft:

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

Throughout the history of this document we have included, excluded,
added and removed various attributes to get the scope of the document
just right.   We have been balancing the tradeoff of getting a
reasonable focused set of attributes in a single document without
creating a slew of attribute documents to run through the process.
Also, we are addressing the needs and requests of other SDOs for
completing the work on this set of attributes in a timely manner.

I believe we can (and perhaps have) address the issue of compliance to
the spec by indicating in the front matter how NAS devices that do not
support media that provides the functionality controlled by the
attributes in the spec are supposed to behave.  We already have
statements in the spec (section 2.2) that say if you can't support the
functionality requested by the attributes you MUST treat an
Access-Accept as an Reject.  This should be sufficient to allow non VLAN
devices to use this spec and still create an environment with
predictable behavior.

Paul

--
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/>