Minutes interim-2018-core-02: Wed 15:00
minutes-interim-2018-core-02-201808291500-00

(As per https://www.ietf.org/mail-archive/web/core/current/msg09830.html):

Sorry for the short notice on the move to Jitsi; I tried to chase down
the WebEx details but wasn't successful.

We had a short meeting discussing the DOTS work.

Attendees:

Jim Schaad
Peter van der Stok
Klaus Hartke

Minutes:

1.) 3.00 (Alternate Server) response code

draft-ietf-dots-signal-channel-22 proposed a new response code, 3.00
Alternate Server. Since CoAP doesn't have redirects,
draft-ietf-dots-signal-channel-23 now uses the existing 5.03 (Service
Unavailable) response code instead, which seems to work well for the
DOTS case based on the DOTS mailing list discussion. As before, the
response payload provides the details of the alternate server.

Open questions:
* 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?
* Should a more specific media type than "application/cbor" be used?

2.) Hop-Limit option

draft-boucadair-core-hop-limit-00 has been extracted from
draft-ietf-dots-signal-channel-22 and is now referenced by
draft-ietf-dots-signal-channel-23.

The most important part to get right are probably the option
properties. Right now, the draft proposes option number 2, which means
the option is elective and not safe to forward. If there is an
intermediary in the loop that does not recognize the option, this also
means that that intermediary would remove the option before forwarding
the request, so that the request would loop forever. (This might not
happen in the DOTS case, where every intermediary is expected to
support the Hop-Limit option, but it would happen in the general
case.) The option should therefore proabably be safe to forward. The
lowest available option number for {elective, safe to forward, not
part of the cache key} currently is 92.

Open questions:
* Is {elective, safe to forward, not part of the cache key} the right choice?

3.) 5.06 (Hop Limit Reached) response code

A 5.06 response is returned when the hop limit reaches 0. It seems to
make sense to have a dedicated response code for this case, as
intermediaries are expected to extend the information in the payload
and having a dedicated response code would simplify recognizing the
payloads to modify.

It might be noteworthy to point out that, like all error responses, a
5.06 response is cacheable. This means that, if there is a caching
intermediary on the path that does not understand the Hop-Limit option
and if the option is not part of the cache key, then retrying a
request with a larger hop limit might result in a 5.06 response that
was cached for an earlier request with a lower hop limit. If this
behavior is undesirable, then the option should probably be part of
the cache key when unrecognized. The lowest available option number
for {elective, safe to forward, part of the cache key} currently is
16.

Open questions:
* Is {elective, safe to forward, part of the cache key} the better choice?
* Is there a better number than 5.06? (HTTP 506 is: Variant Also
Negotiates [RFC2295])

Klaus