Subject: [core] Suresh Krishnan's No Objection on draft-ietf-core-hop-limit-06: (with COMMENT)

From: Suresh Krishnan via Datatracker <[email-masked]>
Date: Mon, 14 Oct 2019 20:08:20 -0700

Suresh Krishnan has entered the following ballot position for
draft-ietf-core-hop-limit-06: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-core-hop-limit/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

* Section 3

"CoAP messages received with a Hop-Limit option ... ***greater than '255'***
MUST be rejected"

Since the field is only 8 bits long this will never happen, right? If so, this
text about >255 needs to be removed.

* I would have expected that a CoAP option with NoCacheKey bits all zero would
need to match in order to be served from the cache. Checking also for smaller
values of Hop Limit for sending stored responses seems to (IMHO) complicate
things for little benefit.

---

From: <[email-masked]>
Date: Tue, 15 Oct 2019 09:00:53 +0000

Hi Suresh, 

Thank you for the review.

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Suresh Krishnan via Datatracker [mailto:[email-masked]]
> Envoyé : mardi 15 octobre 2019 05:08
> À : The IESG
> Cc : [email-masked]; Jaime Jimenez; core-
> [email-masked]; [email-masked]; [email-masked]
> Objet : Suresh Krishnan's No Objection on draft-ietf-core-hop-limit-06:
> (with COMMENT)
> 

[Med] The range is provided because the option format is said to be uint:

   The value of the Hop-Limit option is encoded as an unsigned integer
                                                      ^^^^^^^^^^^^^^^^
   (see Section 3.2 of [RFC7252]).  This value MUST be between 1 and 255
   inclusive.

Which leads to the Length of 1 byte depicted in Table 1.  

> need to match in order to be served from the cache. 

[Med] We allow to serve from the cache even for lower values when a negative response is cached. If a loop is encountered for, e.g., a hl=15, it will be encountered for a small value, e.g., hl=13. 

Checking also for
> smaller

[Med] If there is going to be caching, then every proxy in the chain is likely to cache the response. So, the request will get no further than the first proxy (with the high hop-limit value).