Subject: Re: [core] A couple of late comments on Hop-Limit

From: Christer Holmberg <[email-masked]>
Date: Wed, 16 Oct 2019 11:19:09 +0000

Hi,

Regarding Q2, I note that the document actually does define a new response code,  Hop Limit Reached. So, it withdraw that part of my comment. Sorry for the confusion.

But, then my question is why the text says that a server/proxy must send 4.00 Bad Request? Should that be replaced with the new Hop Limit Reached response code?

Regards,

Christer

From: core <[email-masked]> on behalf of Christer Holmberg <christer.holmberg=[email-masked]>
Date: Wednesday, 16 October 2019 at 13.13
To: "[email-masked]" <[email-masked]>
Subject: [core] A couple of late comments on Hop-Limit

Hi,

I haven’t followed the hop-limit discussions, so I apologize if the following has already been discussed. I also know that my comments come very late in the process, so sorry for that.

Adam may have an opinion regarding Q2.

Q1:

The draft talks about “CoAP messages”. But, if I understand correctly, it is only intended to be used for CoAP request messages, right?

  *   Since you use a CoAP option, the mechanism can’t be used in an empty message.
  *   I assume you don’t want to use the mechanism when sending a response, because then there is a risk that the client will not receive it.

Unless I’ve missed it, I think it should be more explicit what the applicability of the mechanism is.

Q2:

The draft says that a CoAP message with the Hop-Limit option value set to 0 bigger than 255 must be rejected with a 4.00 Bad Request response.

  *   Is 4.00 really an appropriate response code? When reading the HTTP definition for 400 Bad Request (CoAP inherits the semantics), it is about a client error (miss formed message, etc), which is not the case here.
  *   Based on my experience in SIP, it is VERY useful to have a dedicated response code for this (SIP defines ‘483 Too Many Hops’). Because, when this happens, it is often related to *network configuration and/or routing issues* – not to client implementation issues – so it is VERY useful information when trying to figure out why the message was rejected.

Regards,

Christer