[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Dime] [AAA-DOCTORS] AD Review of dime-qos-parameters-06.txt
Hi Mikko,
the reason is that we essentially "copied" the format defined in the NSIS
group as they have been working on the definition of the QoS parameters.
In the past folks in DIME did not have a problem with the format and I also
specifically asked for feedback on this issue.
In fact, I even compiled a version of the draft with Diameter encoding once:
http://tools.ietf.org/html/draft-ietf-dime-qos-parameters-05
As one can see from that document it isn't totally easy either to use
Diameter AVPs as the format that is being referenced comes directly from a
various RFCs and there is the obvious question whether the format should be
taken as is or also "translated". For example, take a look at Section
3.11.3. of http://tools.ietf.org/html/draft-ietf-dime-qos-parameters-05
(PHB-Class AVP).
Ciao
Hannes
>-----Original Message-----
>From: mikko.aittola@nokia.com [mailto:mikko.aittola@nokia.com]
>Sent: 11 November, 2008 16:24
>To: Hannes.Tschofenig@gmx.net; dime@ietf.org
>Cc: aaa-doctors@ietf.org; radiusext@ops.ietf.org
>Subject: RE: [Dime] [AAA-DOCTORS] AD Review of
>dime-qos-parameters-06.txt
>
>Hi,
>
>Would it be useful to add some text to the draft to explain
>and justify the usage of the encoding format that you've
>chosen for the qos parameters?
>
>It is not obvious why is it be better to define separate qos
>parameter header and formats instead of using normal Diameter
>AVP header and formats to transfer the data.
>
>
>BR,
>Mikko
>
>
>>-----Original Message-----
>>From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On
>Behalf Of
>>ext Hannes Tschofenig
>>Sent: 11 November, 2008 14:21
>>To: 'David B. Nelson'; dime@ietf.org
>>Cc: aaa-doctors@ietf.org; radiusext@ops.ietf.org
>>Subject: Re: [Dime] [AAA-DOCTORS] AD Review of
>>dime-qos-parameters-06.txt
>>
>>Hi David,
>>
>>
>>>Hannes Tschofenig writes...
>>>
>>>> * 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.
>>>
>>>The RADIUS Design Guidelines document is pragmatic. It
>>>*strongly* suggests (SHOULD not MUST) that attributes which could
>>>reasonably be implemented in a data-dictionary driven RADIUS
>server as
>>>data dictionary entries be encoded in the standard encoding.
>>>Exceptions are made for (a) attributes which would
>absolutely require
>>>code changes in the server, (b) attributes used as authentication
>>>credentials payloads, and
>>>(c) attributes which are opaque to the RADIUS server and
>>RADIUS client.
>>
>>I don't think that attributes can be opaque to the RADIUS
>client since
>>the client has todo something with them.
>>
>>The attributes are opaque to the RADIUS server and the respective
>>component (dealing with policy-based admission control) needs to be
>>implemented (=code changes).
>>
>>>
>>>This is not a matter of aesthetics or personal design choice
>>>-- it is dictated by the usage.
>>>
>>>BTW, *my* definition of opaque means that the data field of
>>>the attribute, as described in the RADIUS document is a single
>>>string, whose contents are defined in some non-RADIUS
>>>document. Once the RADIUS attribute definition starts
>>>breaking the attribute data payload into sub-fields it really
>>>isn't opaque anymore.
>>
>>Currently, we do not yet define the RADIUS attributes (and
>>that would be a
>>RADEXT document) but they will then be defined as a string and
>>within that
>>string there will be the content of the QoS parameters.
>>
>>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/>