%% You should probably cite rfc7967 instead of this I-D.
@techreport{tcs-coap-no-response-option-14,
    number =    {draft-tcs-coap-no-response-option-14},
    type =      {Internet-Draft},
    institution =   {Internet Engineering Task Force},
    publisher = {Internet Engineering Task Force},
    note =      {Work in Progress},
    url =       {https://datatracker.ietf.org/doc/draft-tcs-coap-no-response-option/14/},
    author =    {Abhijan Bhattacharyya and Soma Bandyopadhyay and Arpan Pal and Tulika Bose},
    title =     {{CoAP option for no server-response}},
    pagetotal = 17,
    year =      2016,
    month =     feb,
    day =       17,
    abstract =  {There can be M2M scenarios where responses from a server against requests from client are redundant. This kind of open-loop exchange (with no response path from the server to the client) may be desired to minimize resource consumption in constrained systems while updating a bulk of resources simultaneously, or updating a resource with a very high frequency. CoAP already provides a non-confirmable (NON) mode of message exchange where the server end-point does not respond with ACK. However, obeying the request/response semantics, the server end-point responds back with a status code indicating "the result of the attempt to understand and satisfy the request". This document introduces a header option for CoAP called 'No- Response'. Using this option the client can explicitly tell the server to suppress all responses against the particular request. This option also provides granular control to enable suppression of a particular class of response or a combination of response-classes. This option may be effective for both unicast and multicast requests. This document also discusses a few exemplary applications which benefit from this option.},
}