RE: Issue 110: Compliance and Coherence

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

At IETF-64 we discussed this issue and I believe the consensus regarding
this was that we will NOT split the draft into two or more drafts with
fewer attributes and that the current statement in section 2.2 was
sufficient to describe compliance. 

> -----Original Message-----
> From: owner-radiusext@ops.ietf.org 
> [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Congdon, 
> Paul T (ProCurve)
> Sent: Wednesday, September 21, 2005 2:10 PM
> To: radiusext@ops.ietf.org
> Cc: gdweber@cisco.com
> Subject: Issue 110: Compliance and Coherence
> Importance: High
> 
> 
> 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/>
> 

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