Re: [core] RFC 8516 on "Too Many Requests" Response Code for the Constrained Application Protocol

Thank you, Ari, for pulling this through.

Ari submitted the first individual I-D for this on 2018-03-05:
The process up to publication went through in less than 11 months.
(The document approval was 2018-11-19, so the RFC editing was responsible for the last two of those months, which includes two heavy vacation periods in US and Europe, so was much less net time.)

Not bad, but let’s see if we can get better yet.

Grüße, Carsten

> On Jan 23, 2019, at 05:48, rfc-editor@rfc-editor.org wrote:
> 
> A new Request for Comments is now available in online RFC libraries.
> 
> 
>        RFC 8516
> 
>        Title:      "Too Many Requests" Response Code 
>                    for the Constrained Application Protocol 
>        Author:     A. Keränen
>        Status:     Standards Track
>        Stream:     IETF
>        Date:       January 2019
>        Mailbox:    ari.keranen@ericsson.com
>        Pages:      6
>        Characters: 11786
>        Updates/Obsoletes/SeeAlso:   None
> 
>        I-D Tag:    draft-ietf-core-too-many-reqs-06.txt
> 
>        URL:        https://www.rfc-editor.org/info/rfc8516
> 
>        DOI:        10.17487/RFC8516
> 
> A Constrained Application Protocol (CoAP) server can experience
> temporary overload because one or more clients are sending requests
> to the server at a higher rate than the server is capable or willing
> to handle.  This document defines a new CoAP response code for a
> server to indicate that a client should reduce the rate of requests.
> 
> This document is a product of the Constrained RESTful Environments Working Group of the IETF.
> 
> This is now a Proposed Standard.
> 
> STANDARDS TRACK: This document specifies an Internet Standards Track
> protocol for the Internet community, and requests discussion and suggestions
> for improvements.  Please refer to the current edition of the Official
> Internet Protocol Standards (https://www.rfc-editor.org/standards) for the 
> standardization state and status of this protocol.  Distribution of this 
> memo is unlimited.
> 
> This announcement is sent to the IETF-Announce and rfc-dist lists.
> To subscribe or unsubscribe, see
>  https://www.ietf.org/mailman/listinfo/ietf-announce
>  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist
> 
> For searching the RFC series, see https://www.rfc-editor.org/search
> For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk
> 
> Requests for special distribution should be addressed to either the
> author of the RFC in question, or to rfc-editor@rfc-editor.org.  Unless
> specifically noted otherwise on the RFC itself, all RFCs are for
> unlimited distribution.
> 
> 
> The RFC Editor Team
> Association Management Solutions, LLC
> 
> 
> 