Re: [art] Artart telechat review of draft-ietf-tram-stunbis-16

[Peter Saint-Andre <[e-mail]>]

On 4/21/18 3:39 PM, Marc Petit-Huguenin wrote:

>>>>> Section 6.3.4 states:
>>>>>
>>>>>    o  If the error code is 500 through 599, the client MAY resend the
>>>>>       request; clients that do so MUST limit the number of times they do
>>>>>       this.
>>>>>
>>>>> It is reasonable to provide guidance as to the number of re-sends?
>>>>
>>>> Same issue here, that's a section that is unmodified from RFC 5389. 
>>>
>>> I understand. Now is our chance to fix it. :-)
>>>
>>>>  As long as the client does not enter an endless loop of retransmission, choosing different numbers of re-sends does not affect interoperability.
>>>
>>> Choosing different numbers is OK, but choosing an infinite number is
>>> not. Can we provide guidance as to how many is too many? 10? 50? 100?
>>
>> Well, the text already states that an infinite number of of re-sends is not compliant.  Anyway, I am not sure how to determine a reasonable number, but I'll try.
> 
> I chose 4 as the maximum number of retransmissions.  I based that on error code 508 in TURN that defines a delay of 60 seconds between retransmissions, so we now get a delay of 5 minutes before the client gives up in case of insufficient capacity.  The new text reads like this:
> 
> "o  If the error code is 500 through 599, the client MAY resend the
>     request; clients that do so MUST limit the number of times they do
>     this.  Unless a specific error code specifies a different value,
>     the number of retransmissions MUST be limited to 4."
> 

"SHOULD be limited to 4" seems fine, but MUST is OK too.

Thanks for looking into this and making the fix.

Peter