%% You should probably cite rfc7967 instead of this I-D.
@techreport{tcs-coap-no-response-option-15,
    number =    {draft-tcs-coap-no-response-option-15},
    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/15/},
    author =    {Abhijan Bhattacharyya and Soma Bandyopadhyay and Arpan Pal and Tulika Bose},
    title =     {{CoAP option for no server-response}},
    pagetotal = 18,
    year =      2016,
    month =     apr,
    day =       4,
    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 Non-confirmable (NON) messages that are not acknowledged by the recipient. However, the request/response semantics still require the server to respond with a status code indicating "the result of the attempt to understand and satisfy the request". This specification introduces a CoAP option 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.},
}