RE: Issue 130: Diameter Compatibility (IEEE 802 Last call)

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

I'd like to test the consensus from IETF-64 on this issue.  I believe we
agreed that we would not split-up the attribute into multiple attributes
because of the ordering issues.  I also believe we agreed to define the
Radius attribute as needed and provide compatibility and
interoperability with Diameter using existing practices for supporting
Radius attributes in Diameter.  This would imply that we need to rename
the current NAS-Filter-Rule attribute to something else in order to
avoid confusion with Diameter's AVP. 

> -----Original Message-----
> From: owner-radiusext@ops.ietf.org 
> [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Sanchez, 
> Mauricio (PNB Roseville)
> Sent: Thursday, September 08, 2005 2:56 PM
> To: radiusext@ops.ietf.org
> Subject: Issue 130: Diameter Compatibility (IEEE 802 Last call) 
> 
> 
> Bernard writes... 
> 
> > Issue 130: Diameter Compatibility
> > Submitter name: Bernard Aboba
> > Submitter email address: aboba@internaut.com Date first
> > submitted: August 29, 2005
> > Reference: 
> > Document: IEEE802-00
> > Comment type: T
> > Priority: S
> > Section: Various
> > Rationale/Explanation of issue:
> > The document does not contain a Diameter Compatibility section, as 
> > required by the RADEXT WG charter.
> > 
> > In reviewing the document, there appears to a major compatibility 
> > problem between this document and Diameter NASREQ (RFC 4005).
> > 
> > The NAS-Filter-Rule attribute defined in the document is not 
> > compatible with the NAS-Filter-Rule attribute defined in RFC 4005, 
> > which is based on the IPFilterRule type defined in RFC 3588.
> > This incompatibility will break RADIUS/Diameter gateways. 
> > [Jari Arkko]  This is a problem. 
> > 
> > My suggestion is to define the restrict the NAS-Filter-Rule 
> attribute 
> > to the RFC 3588 syntax, and define additional attributes for other 
> > purposes, such as Layer 2 filtering and HTTP redirect. It 
> is ok if the 
> > same general syntax is used for these other filters, but 
> they need to 
> > be defined as separate attributes to enable translation of 
> > NAS-Filter-Rule AVP from RADIUS to Diameter and back.
> > [Jari Arkko] Sounds like a good suggestion to me. 
> > [John Loughney] I agree. Bernard's proposal seems reasonable. 
> 
> Say we did break out NAS-Filter-Rule into multiple 
> attributes, each with its own type value.  How would I be 
> able to guarantee strict ordering, given that RADIUS proxies 
> do not have to preserve order for attributes of different 
> types?  Maintenance of order is vital.
> 
> Cheers,
> MS 
> 
> --
> 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/>