Re: [core] Ben Campbell's No Objection on draft-ietf-core-too-many-reqs-05: (with COMMENT)

[Ben Campbell <[e-mail]>]

> On Nov 1, 2018, at 7:50 AM, Ari Keränen <[e-mail]> wrote:
> 
> Hi Ben,
> 
> (Clipping out all except the remaining comment; see below)
> 
> On 24 Oct 2018, at 20.37, Ben Campbell <[e-mail]> wrote:
>>> On Oct 24, 2018, at 1:48 AM, Ari Keränen <[e-mail]> wrote:
>>> On 24 Oct 2018, at 1.08, Ben Campbell <[e-mail]> wrote:
>>> 
>>>> Ben Campbell has entered the following ballot position for
>>>> draft-ietf-core-too-many-reqs-05: No Objection
>>> [...]
>>>> ----------------------------------------------------------------------
>>>> COMMENT:
>>>> ----------------------------------------------------------------------
> [...]
>>>> §4: "A client MUST NOT rely on a server being able to send the 4.29
>>>> Response Code in an overload situation because an overloaded server
>>>> may not be able to reply at all to some requests."
>>>> 
>>>> Can you elaborate on the practical effect of that MUST NOT?
>>> 
>>> Client should not make assumptions, e.g., that it can safely keep increasing the request rate until it receives 4.29, even if a server supports that.
>> 
>> That seems kind of vague for a normative MUST NOT. How did clients pace requests prior to this? Are we asking them to do something different
> 
> Basic CoAP implementations using default values would have just a single request on fly, but more advanced implementation could have more e.g., based on RTT estimates. The key point here is that this error code should not be used to probe a limit the server can handle. So it’s not really any new behavior this draft is asking for, rather a hint that this code should *not* be used for this (probing) kind of “new behavior”.
> 
> What would you recommend instead of MUST NOT here? Would “should not” be more appropriate?

That would work for me.

Thanks!

Ben.