[core] draft-ietf-core-hop-limit-00

[Klaus Hartke <[e-mail]>]

Hi authors of draft-ietf-core-hop-limit,

the draft was discussed a couple of times in the recent virtual
interims of CoRE, but I'm not sure if the conclusions ever made it the
mailing list.

We discussed the open questions from the August 29 virtual interim
[1], with the following conclusions:

> * Would it be useful to have a general-purpose content format for
> providing details of an alternate server, or is the information too
> DOTS-specific?

In general, a general-purpose content format would be nice, but for
now a DOTS-specific content format is fine.

> * Should a more specific media type than "application/cbor" be used?

Yes. (draft-ietf-dots-signal-channel now uses "application/dots+cbor".)

> * Is {elective, safe to forward, not part of the cache key} the right choice?
> * Is {elective, safe to forward, part of the cache key} the better choice?

The option should be elective, safe-to-forward, and part of the cache
key. If a cache understands the option, it should perform a
greater-than-or-equals comparison instead of just checking for
equality of the option value.

> * Is there a better number than 5.06? (HTTP 506 is: Variant Also
> Negotiates [RFC2295])

Allocating response code 5.06 for "Hop Limit Reached" is fine, since
"Variant Also Negotiates" is unlikely to make it into CoAP.

Best regards,
Klaus

[1] https://www.ietf.org/mail-archive/web/core/current/msg09830.html