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

[<[e-mail]>]

Hi Suresh, 

Thank you for the review.

Please see inline. 

Cheers,
Med

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

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

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

[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
> values of Hop Limit for sending stored responses seems to (IMHO) complicate
> things for little benefit.

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