Re: [core] BG1 -- CoAP Ping (Re: draft-ietf-core-coap-13 WGLC - my comments)

[Andrew McGregor <[e-mail]>]

Simply deleting the "and MUST NOT be empty" from the first sentence you quote would make it unambiguous that an empty message is allowed, and must be rejected.

Andrew

On 4/01/2013, at 4:17 PM, Bert Greevenbosch <[e-mail]> wrote:

> Hi Carsten,
> 
> I agree that we should not define a separate NOOP method just for verification if the server is running.
> 
> I guess the following text is what makes the suggested method work:
> 
>   A Confirmable message
>   always carries either a request or response and MUST NOT be empty.  A
>   recipient MUST acknowledge such a message with an Acknowledgement
>   message or, if it lacks context to process the message properly
>   (including the case where the message is empty or has a message
>   format error), MUST reject it; rejecting a Confirmable message is
>   effected by sending a matching Reset message and otherwise ignoring
>   it.
> 
> I don't feel too strong about this. It is just that the spec seems to endorse violating its own MUST NOTs. But that discussion might be more philosophical than it is technical...
> 
> Happy new year!
> Bert
> 
> 
> -----Original Message-----
> From: Carsten Bormann [mailto:[e-mail]] 
> Sent: 21 December 2012 15:36
> To: Bert Greevenbosch
> Cc: [e-mail] WG
> Subject: BG1 -- CoAP Ping (Re: [core] draft-ietf-core-coap-13 WGLC - my comments)
> 
> Hi Bert,
> 
> I'll pick some of your comments and reply with my personal view.
> I'll construct a separate subject for each so we have some threading if the discussion continues.
> 
> On Dec 21, 2012, at 03:42, Bert Greevenbosch <[e-mail]> wrote:
> 
>> 1,E) p.9: "Provoking a Reset message (e.g., by sending an empty Confirmable message) is also useful as an inexpensive check of the liveness of an endpoint ("CoAP ping")."
>> I am not sure if we should endorse provoking RST messages by sending empty CON messages.
> 
> We have found that it is very useful to have some lightweight "are you there" mechanism.
> This is both for diagnostics, and for address selection ahead of a heavy-weight non-idempotent operation.
> 
> Now we could define a NOOP method that does nothing.  In a Confirmable message, this would elicit an empty ACK.
> In total, this would look a lot like the mechanism described above, but with a "positive" ACK.
> 4-byte request, 4-byte ACK.
> 
> However, the empty/RST exchange has essentially the same properties, with the simple advantage that you already (should) have implemented it.
> One method less, requires no additional code.
> Calling it out here was motivated by noticing that not every implementation before ETSI CoAP2 caught the MUSTs that make it work.
> 
> One could argue that a ping that "works" should not end in an "error" message like RST.
> However, there are other cases where a RST is somewhat "normal", so seeing a RST should not be raising red alarms anyway.
> 
> So I agree a bit with the sentiment you are expressing, but I think it is not sufficient reason to add a NOOP method.
> (I also briefly thought about instead adding an ECHO method (sends back the payload) so you can run diagnostics with different packet sizes.
> With a payload of 0 bytes, this becomes similar to NOOP, except that the ACK would carry a response code.
> Also sounds somewhat useful, but do we really need it?  
> We most likely don't want an equivalent of CHARGEN, as this would be inviting amplification attacks.)
> 
> Grüße, Carsten
> 
> _______________________________________________
> core mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/core