%% You should probably cite rfc7967 instead of this I-D.
@techreport{tcs-coap-no-response-option-12,
    number =    {draft-tcs-coap-no-response-option-12},
    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/12/},
    author =    {Abhijan Bhattacharyya and Soma Bandyopadhyay and Arpan Pal and Tulika Bose},
    title =     {{CoAP option for no server-response}},
    pagetotal = 17,
    year =      2015,
    month =     oct,
    day =       15,
    abstract =  {There can be M2M scenarios where responses from server against requests from client might be considered 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 simultaneously updating a bulk of resources 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 draft introduces a header option for CoAP called 'No-Response'. Using this option the client explicitly tells the server to suppress responses against the particular request. This option also provides granular control to enable suppression of a particular class or a combination of response-classes. This option may be effective for both unicast and multicast requests. Present draft also discusses few exemplary applications which benefit from this option.},
}