[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Diameter Considerations Section



That's my reading as well.

John 

>-----Original Message-----
>From: owner-radiusext@ops.ietf.org 
>[mailto:owner-radiusext@ops.ietf.org] On Behalf Of ext Nelson, David
>Sent: 09 June, 2006 23:28
>To: radiusext@ops.ietf.org
>Subject: RE: Diameter Considerations Section
>
>Glen Zorn writes...
>
>> IIRC, the intent was that Diameter would (MUST) support all standard 
>> RADIUS attributes.  Of course, at the time it was (rather naively) 
>> supposed that no more standard RADIUS attributes would be defined.
>Given
>> this, I don't really think that new App-Ids need to be assigned; in
>fact,
>> if such an assignment took place, I would argue that the 
>attributes in 
>> question should be mapped to new Diameter AVPs, rather than 
>handled in
>the
>> same way as legacy standard RADIUS attributes.
>
>I think this is correct.  Since RADIUS does not have the 
>notion of Application IDs, then all RADIUS attributes that are 
>"imported" to Diameter via the RFC 4005 mechanism ought to 
>have the same Diameter Application ID.
>
>
>--
>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/>