Re: [core] New draft-tiloca-core-groupcomm-proxy on proxied CoAP multicast operation

[Christian Amsüss <[e-mail]>]

Hello Esko,

thanks for your responses, I'll add where I think there should be more
discussion:

> * Response-Forwarding: Is this expected to be extensible to any other
>   CoAP transport that may come up that supports multicast? The use of
>   CBOR tags seems to imply that, but then there's the question of how
>   the client would arrive at a URI for follow-up unicast communication.
> 
>   Have you considered just using values that'd go into Uri-Host in a
>   follow-up request?
> 
> [GP] The use of CBOR tags was not on purpose to be prepared for future
> transports. It was more re-using a convention that was already there.
> But by doing it this way we are prepared for potential future
> transports, in which something else than an IPv4 or IPv6 or MAC
> address needs to be sent back to the client.
>
> The current encoding is expected to be more efficient than providing
> an IP address as a Uri-Host string. The current encoding can also be
> re-used in a Uri-Host or Uri-Proxy Option sent towards a proxy,
> although the client needs to do some transcoding to get it into the
> string format used by CoAP.
>
> If the client uses a direct unicast connection to reach the server
> (maybe this use case is less common?) then it doesn't use the returned
> IP address in the CoAP request; it will only use it in the destination
> IP address of the IP packet that is sent and then having it in a
> byte-by-byte format is quite useful.

I see the point of not having to deal with the human-readable encoding;
still I'd prefer more consistency with the return CoAP options. (And I
agree that proxy-then-direct would be a rare case, though I can imagine
cases).

We might consider (possibly outside this document) the introduction of a
Uri-Host-Binary option, which would be mutually exclusive with Uri-Host
and 1:1 mappable (at any time by any intermediary) to the subset of
Uri-Hosts that are IP literals and ideally compatible with the host.ip
production of CoRAL.

Then, a Response-Forwarding response option (or something from it, if
typing stays or the below is added) could be used directly in the
follow-up request as part of the request URI.

By the way, as the topic of multicast responses from a different port
has come up recently, how would those be expressed?


> * Why is the information about the client being behind a proxy
>   forwarded? We don't to this in other proxying cases, and it just puts
>   an additional burden on the origin server I don't see a compelling
>   need for.
> 
> [...]
> We opted for the current end-to-end solution to have the extra
> information (in both ways) secured so the Proxy can't tamper with it.
> (This works in combination with OSCORE.)

OSCORE itself does not protect the address with good reason, one of them
being that the actual OSCORE server might be proxied behind the node.

If we let the proxy change the source address, there's no harm done to
later communication (as the proxy can just as well send the messages
somewhere else again).


> * At some point, as a WG we will need to think of whether we really want
>   to have another option with Observe-like multiresponses; Block-wise
>   and Observe being the two extensions so early everyone knew from
>   RFC7252 they would come does put them into a special position.
> 
>   [...]
> 
> [GP] The concept of multiple responses (by the Proxy) to a client's
> request is already defined in RFC 7252 so it is not 'new' in that
> sense. The use of the Options as we define it, doesn't change that
> behavior.

Indeed, but groupcomm (to which is referred for details there; similar
in groupcomm-bis) says that this SHOULD NOT be done unless there is
explicit configuration and the client.

If we introduce this option here to be that configuration, this is what
enables the behavior in the first place for out-of-the-box
configurations.

(That is still not saying I'm not OK with making this one of the two
options that an intermediary may recognize as "expects more than one
response", just looking to explore the space.)

> Also in draft-ietf-core-groupcomm-bis we discuss the longer-lived
> Tokens issue; so that's inherently present in multicast situations
> (proxied or not).
>
> Maybe we could use draft-ietf-core-groupcomm-bis to define the more
> general long-lived-token mechanisms? (Not sure yet what these would
> be, in general.)

For multicast that's good to have; a summary of cases ("expects one
response", "expects arbitrarily many responses inside
MIN_TOKEN_REUSE_TIME", "expects aribitrarily many responses as long as
there's always an older almost-still-fresh response") might be material
for clar-corr.

KR
c

-- 
Build a man a fire, and he'll be warm for a day. Set a man on fire, and
he'll be warm for the rest of his life.
  -- Terry Pratchett (attributed)