Re: [core] Please have another look at no-response (Re: WG last-call (WGLC) of draft-ietf-core-http-mapping-07)

[Abhijan Bhattacharyya <[e-mail]>]

Hi Esko,
Thanks for your detail comments and your support. Here are my responses:

> I did not understand fully why the document is not going to be a WG 
> draft.

We could not get enough hands raised for WG adaptation. :) So taking the 
individual submission route as suggested by Carsten.

> 1.
> “Using this option with CON type of requests may not have any
>       significance if piggybacked responses are triggered. Even if the
>       response is suppressed it does not reduce any traffic in that
>       case.”
> 
> I don’t fully agree with the second sentence; since an ACK message 
> without the response inside can be very short while an ACK with the 
> complete response (payload) inside can be quite lengthy. The first 
> sentence I agree with (“may not have any significance” suggests that
> in some cases it *may* have significance).

Good point. Accepted. May be the 'may' should be "MAY". :))

> Also in the same paragraph “reduces one additional traffic” -> maybe
> replace it by “reduce traffic by one message” to be more correct.

OK

> 2.
> “This option is not applicable and should have no effect for usual
>    GET requests asking for resource representation.”
> 
> Don’t agree on this – the option should just do its work whether it 
> is inside a GET, PUT, POST or DELETE. 

Actually we did not have any use case which would require a GET not to 
send any response payload, other than the case of observe-cancellation. We 
kept the restriction to ensure that any accidental use of No-Response with 
usual GET does not suppress the response payload, which would be actually 
intended. If you have any use case then would request you to please share.

> 3. Table 2, row DELETE: remove the SHOULD / SHOULD NOT language here
> perhaps? ....

OK

> 4. Section 1: “This option enables to express disinterest in all 
> kinds of response by default.” -> incorrect, by default it expresses
> interest in all classes. Also replace “kinds” by “classes” preferably.

Yes. This error crept in after we changed the option values in the last 
draft. Will correct.

> 5. Table 3, first row: “<empty>” is possible but also 00000000 
> binary is possible there – by making the option length 1 instead of 
> 0.

This is done in accordance with canonical representation. There was some 
discussion in the past on this in mailing list.

> 6. Section 4.1: “However, a request with No-Response does not have 
> any response path.”
> -> replace by “However, a request with No-Response typically does 
> not have a guaranteed response path.”

O.K.

> 7. Section 4.1: “SHOULD use a unique token for request with No-
> Response” -> “SHOULD use a unique token for each request with No-
> Response to the same server endpoint”

OK. Good to be precise.

> 8. Section 4.1 starting with “NON_LIFETIME and MAX_LATENCY are 
> defined in 4.8.2 ….” up to the end of the section: I don’t 
> understand here why “Leisure” and the equations are used here for 
> unicast requests. It is only defined in RFC 7252 for multicast 
> requests and their associated unicast response. Suggestion: replace 
> text by something that does not depend on Leisure.  (Or else 
> describe why Leisure plays a role for unicast requests!)

'Leisure' is a component of the total time the client should wait when 
suppressing responses selectively. We are re-using the definition of the 
leisure as a common parameter for both unicast and multicast. We just 
wanted to keep clarity on how leisure can be defined as a general 
definition and unicast  becomes a special case.

Regards
Abhijan Bhattacharyya
Associate Consultant
Scientist, Innovation Lab, Kolkata, India
Tata Consultancy Services
Mailto: [e-mail]
Website: http://www.tcs.com
____________________________________________
Experience certainty.   IT Services
                        Business Solutions
                        Consulting
____________________________________________


"Dijk, Esko" <[e-mail]> wrote on 10/13/2015 09:18:24 PM:

> From: "Dijk, Esko" <[e-mail]>
> To: Abhijan Bhattacharyya <[e-mail]>, Carsten 
> Bormann <[e-mail]>
> Cc: "[e-mail] WG" <[e-mail]>
> Date: 10/13/2015 09:20 PM
> Subject: RE: [core] Please have another look at no-response (Re: WG 
> last-call (WGLC) of draft-ietf-core-http-mapping-07)
> 
> Hello Abhijan, Carsten,
> 
> Below some more review comments for this draft!  Some points may be 
> a repetition of some of my previous review comments but I send them 
> nevertheless.
> I did not understand fully why the document is not going to be a WG 
> draft. I did miss the discussion on this. Anyhow it appears to me as
> a quite useful option to have in the “official” CoAP repertoire. 
> 
> 1.
> “Using this option with CON type of requests may not have any
>       significance if piggybacked responses are triggered. Even if the
>       response is suppressed it does not reduce any traffic in that
>       case.”
> 
> I don’t fully agree with the second sentence; since an ACK message 
> without the response inside can be very short while an ACK with the 
> complete response (payload) inside can be quite lengthy. The first 
> sentence I agree with (“may not have any significance” suggests that
> in some cases it *may* have significance).
> 
> Also in the same paragraph “reduces one additional traffic” -> maybe
> replace it by “reduce traffic by one message” to be more correct.
> 
> 2.
> “This option is not applicable and should have no effect for usual
>    GET requests asking for resource representation.”
> 
> Don’t agree on this – the option should just do its work whether it 
> is inside a GET, PUT, POST or DELETE. 
> 
> 3. Table 2, row DELETE: remove the SHOULD / SHOULD NOT language here
> perhaps? Again if a client wants to send DELETE with no-response 
> then the client can do so. The expectation is that the option is 
> parsed by the server and applied, assuming the server knows/
> understands the elective option. On the previous rows a SHOULD NOT 
> etc. was also not necessary.
> 
> 4. Section 1: “This option enables to express disinterest in all 
> kinds of response by default.” -> incorrect, by default it expresses
> interest in all classes. Also replace “kinds” by “classes” preferably.
> 
> 5. Table 3, first row: “<empty>” is possible but also 00000000 
> binary is possible there – by making the option length 1 instead of 
> 0. That has the same effect as empty, so good to list it in the 
> table as well! Maybe within the same table cell.
> 
> 6. Section 4.1: “However, a request with No-Response does not have 
> any response path.”
> -> replace by “However, a request with No-Response typically does 
> not have a guaranteed response path.”
> (since e.g. for the default option value 0 there is a guaranteed 
> response path.)
> 
> 7. Section 4.1: “SHOULD use a unique token for request with No-
> Response” -> “SHOULD use a unique token for each request with No-
> Response to the same server endpoint”
> 
> 8. Section 4.1 starting with “NON_LIFETIME and MAX_LATENCY are 
> defined in 4.8.2 ….” up to the end of the section: I don’t 
> understand here why “Leisure” and the equations are used here for 
> unicast requests. It is only defined in RFC 7252 for multicast 
> requests and their associated unicast response. Suggestion: replace 
> text by something that does not depend on Leisure.  (Or else 
> describe why Leisure plays a role for unicast requests!)
> 
> Best regards
> Esko
> 
> From: core [mailto:[e-mail]] On Behalf Of Abhijan 
Bhattacharyya
> Sent: Tuesday, October 13, 2015 09:44
> To: Carsten Bormann <[e-mail]>
> Cc: core <[e-mail]>; [e-mail] WG <[e-mail]>
> Subject: Re: [core] Please have another look at no-response (Re: WG 
> last-call (WGLC) of draft-ietf-core-http-mapping-07)
> Importance: High
> 
> Hi Carsten, 
> 
> > ... provide Abhijan (and the core WG list, if you like) with your
> > feedback, preferably so that he has time to react before the Yokohama
> > I-D deadline (maybe send in the comments before 2015-10-12). 
> 
> While the tentative deadline set for sharing the comments is over, 
> we have so far received one comment from Akbar. It is about 
> mentioning the behaviour of a reverse proxy in the context of 
> applications requiring No-Response at the CoAP end (http://
> www.ietf.org/mail-archive/web/core/current/msg06506.html). 
> 
> Should we consider the final review process to be over by now? 
> Requesting your suggestion regarding the way forward. 
> Awaiting your response soon as Yokohama deadlines are approaching fast. 
> 
> Regards
> Abhijan Bhattacharyya
> Associate Consultant
> Scientist, Innovation Lab, Kolkata, India
> Tata Consultancy Services
> Mailto: [e-mail]
> Website: http://www.tcs.com
> ____________________________________________
> Experience certainty.        IT Services
>                        Business Solutions
>                        Consulting
> ____________________________________________
> 
> 
> Carsten Bormann <[e-mail]> wrote on 09/24/2015 02:47:07 AM:
> 
> > From: Carsten Bormann <[e-mail]> 
> > To: "Rahman, Akbar" <[e-mail]> 
> > Cc: Abhijan Bhattacharyya <[e-mail]>, core 
> > <[e-mail]>, "[e-mail] WG" <[e-mail]> 
> > Date: 09/24/2015 02:47 AM 
> > Subject: Please have another look at no-response (Re: [core] WG 
> > last-call (WGLC) of draft-ietf-core-http-mapping-07) 
> > 
> > Rahman, Akbar wrote:
> > > Any feedback?
> > 
> > We'll need to have a reference.
> > 
> > That (and the current discussion in ACE about unidirectional 
exchanges)
> > reminds me that the draft for Option 284 could still benefit from some
> > final review.  So, if you are interested in this topic, please have a
> > look at
> > 
> >     
http://tools.ietf.org/html/draft-tcs-coap-no-response-option-11.txt
> > 
> > and provide Abhijan (and the core WG list, if you like) with your
> > feedback, preferably so that he has time to react before the Yokohama
> > I-D deadline (maybe send in the comments before 2015-10-12).
> > 
> > (To avoid confusion, I'll add that we decided not to make a WG 
document
> > out of this option, but there has been some review and some support
> > already, and we all should be interested in facilitating the extension
> > registration processes defined in RFC 7252.)
> > 
> > Grüße, Carsten
> =====-----=====-----=====
> Notice: The information contained in this e-mail
> message and/or attachments to it may contain 
> confidential or privileged information. If you are 
> not the intended recipient, any dissemination, use, 
> review, distribution, printing or copying of the 
> information contained in this e-mail message 
> and/or attachments to it are strictly prohibited. If 
> you have received this communication in error, 
> please notify us by reply e-mail or telephone and 
> immediately and permanently delete the message 
> and any attachments. Thank you
> 
> The information contained in this message may be confidential and 
> legally protected under applicable law. The message is intended 
> solely for the addressee(s). If you are not the intended recipient, 
> you are hereby notified that any use, forwarding, dissemination, or 
> reproduction of this message is strictly prohibited and may be 
> unlawful. If you are not the intended recipient, please contact the 
> sender by return e-mail and destroy all copies of the original message.