Subject: [Dime] draft-ietf-dime-ovli-08 - Result-Code Handling

From: Jens Schendel <[email-masked]>
Date: Wed, 3 Jun 2015 12:52:58 +0000

Hi all,

I have some questions on section "8.  Error Response Codes".

As specified beforehand, reacting nodes are responsible for determining which  treatment is appropriate for individual requests (diversion or throttling).
In the section the error handling for DIAMETER_TOO_BUSY and DIAMETER_UNABLE_TO_COMPLY is described (basically according to Diameter Base) - rather from reporting node point of view. So it may be that according to local policy the reacting node treats to-be-abated messages with throttling per default whereas it may happen that the reporting node in overload condition sets up error response code  DIAMETER_TOO_BUSY for received requests which eventually should lead to retry handling ("diversion"). This would result in inconsistent treatment for let's say "early" and "late" overload treated requests. Is this acceptable?

And another question: Is the mandatory reflection of OC-Supported-Features by the reporting  node still valid for (this) error scenarios? Or in other words, is the reacting node also expected to handle OC-OLR in such error answers (I would doubt at least for 3xxx protocol errors because sender is not expected to conform standard answer message ABNF - but then there might be also inconsistent processing on reacting  node side)?

Jens