RE: [Dime] [AAA-DOCTORS] RADIUS / Diameter compatibilityboilerplate?

["Dave Nelson" <d.b.nelson@comcast.net>]

Hi Hannes,

I've added RADEXT to the distribution, as well.

I agree, based on your summary of the state of the art of translation
gateways and the other issues you highlight, that the simple Diameter
Considerations text that we've been using, modeled after the assumptions of
the Diameter NAS Application (RFC 4005), is a bit misleading.

If the recommendation turns out to be that there should not be simplistic
RADIUS to Diameter interoperability, then I think there are two follow up
issues:

(1) Guidance on when Diameter clients and servers can and cannot use (or
re-use) RADIUS attributes in the legacy <255 ID space.

(2) A prohibition on Diameter documents defining and new AVPs in the legacy
<255 ID space.

I think there was an assumption that any attributes/AVPs in the legacy ID
space would be interchangeable, is a simple fashion.

Regards,

Dave

-----Original Message-----
From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of
Hannes Tschofenig
Sent: Saturday, January 10, 2009 9:03 AM
To: 'David B. Nelson'; Tschofenig, Hannes (NSN - FI/Espoo)
Cc: aaa-doctors@ietf.org; dime@ietf.org
Subject: Re: [Dime] [AAA-DOCTORS] RADIUS / Diameter
compatibilityboilerplate?

Hi Dave, 

Thanks for the reminder. 

Based on the discussion we had with Pasi in context of the MIPv6 integrated
document I tried to figure out how far we are with the deployment of RADIUS
- Diameter translation agents. 

I got feedback, which I will try to summarize (as mentioned in my recent
DIME status update message).

Why does that activity relate to the issue of the boilerplate? We are
writing something in our documents with a certain model of interworking in
mind. For some reason, this interworking does not exist in today's
deployment (based on the feedback I received) and so far I haven't received
evidence that it will exist in the future. 

So, here is my thinking: 

* RADIUS and Diameter are different protocols with different deployment
stories. 

* The data types in RADIUS and Diameter are different. There is overlap but
RADIUS offers fewer data types than Diameter.

* The design considerations in Diameter are different to the one in RADIUS.
A big difference is the fact that Diameter has the concept of applications
and RADIUS doesn't have those (ignoring some tiny details). 

The above-mentioned aspect might lead to different designs in RADIUS and in
Diameter when considering the deployment environment and the available
protocol mechanisms. 

This makes translation more complex. Since there is very little translation
done (other with legacy systems) this does not really matter that much. 

This makes me believe that there should not be a requirement to write RADIUS
Diameter consideration sections in the document. 

If document authors want to include Diameter solution aspects into the same
document then they can obviously do that. This is a pure document management
task. However, they have to consider the entire range of Diameter design
considerations and this may lead to the need to define a Diameter
application and hence the previously short section might be rather long. 

In any case, a WGLC should be posted to the DIME mailing list if there are
Diameter considerations in the document. 

Does this make sense? Feedback from the DIME group? 

Ciao
Hannes

>-----Original Message-----
>From: aaa-doctors-bounces@ietf.org 
>[mailto:aaa-doctors-bounces@ietf.org] On Behalf Of David B. Nelson
>Sent: 08 January, 2009 17:59
>To: 'Tschofenig, Hannes (NSN - FI/Espoo)'
>Cc: aaa-doctors@ietf.org
>Subject: [AAA-DOCTORS] RADIUS / Diameter compatibility boilerplate?
>
>Hi Hannes,
>
>During the AAA Doctors lunch at IETF-73 you volunteered for 
>the action item of drafting some boilerplate / template text 
>for the required Diameter Considerations section of RADIUS 
>I-Ds and RFCs.  How is that coming along?



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