RE: [Dime] [AAA-DOCTORS] AD Review of dime-qos-parameters-06.txt

["Glen Zorn" <glenzorn@comcast.net>]

Tschofenig, Hannes (NSN - FI/Espoo) [mailto:// hannes.tschofenig@nsn.com]
writes:

> Glen,
> 
> >It's very simple: if these attributes/AVPs are meant to be
> >used in RADIUS then do the work in radext (or at the very
> >least, follow the RADIUS design guidelines); note that those
> >attributes could be carried w/o any fuss in Diameter as well.
> >If they are meant to be used in Diameter, then design them as
> >Diameter AVPs, using the features that Diameter enables
> >(grouped AVPs, etc.).  What you have done is neither, and have
> >(predictably) ended up with a mess.
> 
> You obviously don't care too much about my arguments.
> 
> There are three things:
> 
> * The QoS can be carried in RADIUS and Diameter.

If that is the intention, then these should be RADIUS attributes.

> 
> * This approach is totally inline with the RADIUS design guidelines.
> The RADIUS design guidelines document does not require every info
> element to following the standard encoding, as you know.

I think that you've got at least two people who disagree with you on that.

> 
> * Where todo certain documents is a matter of taste and not really a
> bit
> issue (at least so far).

??!  You're not seriously suggesting that Diameter AVPs & RADIUS attributes
are technically equivalent, are you?


> We had a RADIUS draft, as I mentioned, but we focused all our efforts
> on
> the Diameter work.

That's the main problem: the -05 draft contained Diameter AVPs but -06
doesn't.  In fact, this is exactly the kind of application for which
Diameter was designed & I find it rather annoying what's being proposed are
poorly designed RADIUS attributes masquerading as Diameter AVPs.

> 
> Ciao
> Hannes


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