Issue 130: Diameter Compatibility (IEEE 802 Last call)

["Sanchez, Mauricio (PNB Roseville)" <mauricio.sanchez@hp.com>]

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