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