Re: [Dime] [dime] #85 (draft-ietf-dime-ovli): New error response

[Ben Campbell <[e-mail]>]

Not really. I will respond to that email separately.

> On Oct 20, 2014, at 11:59 AM, Steve Donovan <[e-mail]> wrote:
> 
> Ben,
> 
> I attempted to treat them generically in the separate email I sent with the title "[Dime] Proposal for error response wording (issue 85)".
> 
> Does that address your concern?
> 
> Steve
> 
> On 10/20/14, 4:18 PM, Ben Campbell wrote:
>> I think the guidance of agents sending unable-to-comply and servers sending too-busy needs to be pointed out as "typical". There may be cases where the opposites make sense, e.g., if an agent has reason to think an alternate route may be ok (as in agent-overload), it might send too-busy. If a server has reason to believe that the request should not be retried, it can send unable-to-comply.
>> 
>> It's probably best to state this generically based on the expected result (retrying on different route vs final error.), and then describe "typical" behavior for agents and servers.
>> 
>>> On Oct 20, 2014, at 1:38 AM, dime issue tracker <[e-mail]> wrote:
>>> 
>>> #85: New error response
>>> 
>>> 
>>> Comment (by [e-mail]):
>>> 
>>> Raw notes taken from discussion at interim meeting:
>>> 
>>> Requirements
>>> 
>>> •       Current Too-Busy behavior allows for retry
>>> •       Too-Busy was originally defined to have a per connection scope
>>> •       MUST only be used when a specific server exists
>>> o       This might mean that Too-Busy cannot be used for the throttle
>>> error without updating the definition of Too-Busy behavior
>>> •       Unable-to-deliver might be another alternative for throttling
>>> behavior
>>> 
>>> •       Need new error response behavior – DOIC needs error response
>>> behavior to prevent retries due to the message being throttled.
>>> 
>>> •       Need to handle case where transaction client supports the
>>> throttling error behavior and for transaction clients that do not support
>>> the throttling error behavior.
>>> 
>>> Proposal: Use Unable-to-Comply error code when throttling by agent, too-
>>> busy when throttling by server
>>> 
>>> Use case where agent is reacting node – throttled messages should result
>>> in Unable-to-Comply
>>> 
>>> Use case – agent throttling when client supports DOIC unable-to-comply
>>> also works
>>> 
>>> Use case – Server throttling – too-busy works
>>> 
>>> Could add optional “error-diagnostic AVP” to indicate the reason for
>>> unable-to-comply – should be addressed in a separate RFC
>>> 
>>> -- 
>>> -------------------------------------+-------------------------------------
>>> Reporter:                           |       Owner:  draft-ietf-dime-
>>>  [e-mail]           |  [e-mail]
>>>     Type:  defect                   |      Status:  new
>>> Priority:  major                    |   Milestone:
>>> Component:  draft-ietf-dime-ovli     |     Version:
>>> Severity:  Active WG Document       |  Resolution:
>>> Keywords:                           |
>>> -------------------------------------+-------------------------------------
>>> 
>>> Ticket URL: <http://trac.tools.ietf.org/wg/dime/trac/ticket/85#comment:1>
>>> dime <http://tools.ietf.org/wg/dime/>
>>> 
>> 
>