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

[Carsten Bormann <[e-mail]>]

Hi Christer,

On Oct 16, 2019, at 12:13, Christer Holmberg <christer.holmberg=[e-mail]> wrote:
> 
> 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.

Comments are always welcome — it is just less pain to process them when they are early…

> 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.

Hop-Limit Options are indeed meant to be used in CoAP requests.
This needs to be made explicit (*), and it would be a good idea to more specifically talk about requests where the text right now talks about messages that are always requests.

(*) RFC 7252 is not a good role model here; not all descriptions of options make explicit whether the option can be used on requests, responses, or both.  This is certainly one item we can improve when we decide to generate a revision of that RFC.  We are collecting such issues in a github repository; this one now is https://github.com/core-wg/corrclar/issues/12

> 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.

There are two cases here: 0, and > 255.  The latter would be a syntax error for this option; the option description clearly limits the value to a single byte (Table 1).  Zero is not a syntax error, but a value that the authors chose to disallow.

> 	• 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.

A syntax error or a disallowed value in a request is a client error, no?

> 	• Based on my experience in SIP, it is VERY useful to have a dedicated response code for this (SIP defines ‘483 Too Many Hops’).

We do have one for this case: TBA1 | Hop Limit Reached
But this is different from a syntax error.

> 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.

Specific response codes are useful if you want specific state machine transitions to happen, but causing a protocol violation is not really normal behavior, so all we need here are diagnostics.
Please see Sections 5.5.2 and 5.9.2 of RFC 7252.
Section 4 of the draft does define a diagnostic payload for TBA1 | Hop Limit Reached; it could also say something about the bad request case, but maybe the general advice in RFC 7252 is sufficient here.

Grüße, Carsten