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

[Zach Shelby <[e-mail]>]

Andrew,

That would be a reasonable solution. I would suggest we create a ticket to solve Bert's comment in this way.

Zach

On Jan 4, 2013, at 5:45 AM, Andrew McGregor <[e-mail]> wrote:

> 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
> 
> _______________________________________________
> core mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/core

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://www.sensinode.com @SensinodeIoT
Mobile: [phone]
Twitter: @zach_shelby
LinkedIn: http://fi.linkedin.com/in/zachshelby
6LoWPAN Book: http://6lowpan.net