Subject: [core] Interim meeting at 2018-08-29, draft-boucadair-core-hop-limit

From: Carsten Bormann <[email-masked]>
Date: Thu, 23 Aug 2018 09:13:09 +0200

Neither Jaime nor me will be available at the next interim meeting.
Klaus has volunteered to be stand-in chair for this meeting.

My proposal would be that we focus on the DOTS work.  
To prepare, it would be useful to get one more review of draft-boucadair-core-hop-limit before the meeting — who can do that?
The objective should be to be ready for adoption at the interim meeting (Jaime can then run the process from there).
One question was what response code should be used when the hop limit is reached.

We also should look at the way a DOTS server responds requests it cannot handle at the moment.
Again, the response code is one issue; it seems to me that the current draft has already covered the response payload well.
Having one or two reviews of that specific part of draft-ietf-dots-signal-channel would be useful as well.

Grüße, Carsten

---

From: Klaus Hartke <[email-masked]>
Date: Wed, 29 Aug 2018 16:53:17 +0200

The interim meeting today (starting in 7 minutes) will take place on
Jitsi: <https://jitsi.tools.ietf.org/interim-2018-core-02>

Klaus

On Thu, 23 Aug 2018 at 09:13, Carsten Bormann <[email-masked]> wrote:
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: Klaus Hartke <[email-masked]>
Date: Wed, 29 Aug 2018 18:19:01 +0200

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