Re: Issue: Diameter-RADIUS gateway behavior not completely specified

[Barney Wolff <barney@databus.com>]

On Sun, Aug 27, 2006 at 01:57:41PM -0700, Glen Zorn (gwz) wrote:
> 
> > Sigh.  It seems to me that 3588 4.1 at least in spirit says that a
> > gateway getting an attribute with an M-bit that it cannot for
> > whatever reason translate, MUST reject the message.  
> 
> In this case it would be handy if it did, but it doesn't & interpreting
> it that way would violate the M-bit semantics, IMHO.  

Violate in what way?

> > I would truly
> > hate to have to specify gateway behavior for each attribute type, and
> > hate even more having to implement type-specific behavior, just to
> > handle message overflow - or, for that matter, for any other reason. 
> 
> Unfortunately, this problem seems to be the "elephant in the corner" of
> RADIUS-Diameter interop: everybody knows about it (presupposing simple
> arithmetic ability) but nobody wants to talk about it...

Message overflow is a potential problem, sure.  But does dealing with it
actually require different logic depending on what attribute(s) don't fit?
Similarly, does dealing with a single attribute of length >253 actually
have to depend on the attribute type?  Pfui, if so.

-- 
Barney Wolff         I never met a computer I didn't like.

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