Re: [Dime] Proposed Example Text for draft-docdt-dime-ovli-01

[<[e-mail]>]

I could discuss the need for the report type for a longtime...
But I can live with the following approach:

- Keep the report type AVP
- Keep the Report type as optional in the OC-OLR
- Clarify that the OC-OLR applies to the Origin-Host of the Answer when the report type is absent
- Multiple OLRs can be found in the answer only if the OLRs have different Report types e.g. response to an initial request (with only dest-Realm AVP) may contain overload status of the node and of the realm
- Remove "aggregated"

Is it OK for everyone?

Lionel

-----Message d'origine-----
De : DiME [mailto:[e-mail]] De la part de Jouni Korhonen
Envoyé : mercredi 27 novembre 2013 12:59
À : Ben Campbell; [e-mail]
Objet : Re: [Dime] Proposed Example Text for draft-docdt-dime-ovli-01


On Nov 26, 2013, at 10:20 PM, Ben Campbell <[e-mail]> wrote:

> 2)  Lionel argued that OLRs are best used to describe overload for the realm as a whole. Overload for specific nodes would be better handled by sending Diameter error codes, either by fixing one or more existing error codes to have the correct semantics, or introducing new ones. If we did this, we would not need different report types.
> 
> My opinion is that I would like a consistent way of reporting overload, that is, I don't like using OLRs for one kind of overload, and error result codes for another. In particular, I would like to be able to report overload before reaching the point that I need to fail a transaction, i.e. I would like to be able to report any kind of overload in a Diameter answer message with a result code of DIAMETER_SUCCESS.

I am towards Ben's conclusion here.

> 3) Are we allowed to put more than one OLRs in a single answer, as my example shows in step 8?
> 
> It might be possible to construct an example where you never see more than one OLR in a single answer. But I don't see what purpose would be served by such a limitation, as long as multiple OLRs do not contradict each other. Since the reports in the example have different report types, there is no conflict. On disadvantage of _not_ allowing multiple reports in one answer is that, if the servers choose to send reports in every answer, life gets complicated for the agent when trying to find a place to put the "realm" report.  It either needs to strip the server reports (which is hard given that the server overload conditions are best handled by the clients.) Or it needs to originate its own answers, which means forcing the failure of at least some transactions.

My recollection was that we want to get rid off the ReportType in the baseline. That would also imply a single OLR in an answer. I might remember wrong, though.

Anyway, just to be on the safe side the current draft-ietf-*-01 still has the ReportType.

Could we conclude this point asap? Removing the ReportType has implications in multiple places.

- Jouni


_______________________________________________
DiME mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dime

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.