[Dime] [Fwd: Diameter QoS: Feedback ]

[Hannes Tschofenig <Hannes.Tschofenig at gmx.net>]

-- Here is a review by Victor

Ciao
Hannes

--------------------

Hannes,

> > Victor: Could you check the Diameter QoS approach against the 
> > suggestions / guidelines for Diameter Application Design Guidelines 
> > draft?

Sorry for the late reply. I did a quick review and my comments are as 
follows:

a. QAR/QAA and QIR/QAA seems to be straight forward in terms of app-id 
and avp assignments and structure. One minor item in 8.2, QoS info is 
said to be "MUST carry" type information but the ABNF has all of the Qos 
avp as optional. It maybe better to clearly define the meaning of their 
presence/absence in case some other SDOs decide to reuse these messages 
and we end up having dual or overlapping meaning with other optional avps.

b. ACR/ACA ABNF definition also has optional avps for "MUST carry" type 
information same as (a) above. Carrying this avps as "required to exist" 
will also solidify justification of NOT using base accounting.

c. In Sec 6, STR/STA, ASR/ASA, and RAR/RAA commands must carry the 
app-id of diameter QoS and not zero(0); I think all messages in diameter 
Qos should carry the app-id of diameter Qos, including ACR/ACA.

d. For Qos accounting, it may also be beneficial to refer to the 
"Coupled Accounting Service" model defined in Sec 9.3 of 3588bis. Note 
that when using this model, we assume that the accounting messages will 
most likely be routed towards the Authorizing entity. If this is the 
intent then it probably works well since your trying to co-relate Qos 
signaling session, diameter session and application session anyway.


regards,
victor



_______________________________________________
DiME mailing list
DiME at ietf.org
https://www1.ietf.org/mailman/listinfo/dime