[core] Aligning groupcomm-proxy and mutlicast-notifications

"Christian M. Amsüss" <christian@amsuess.com> Tue, 17 November 2020 10:07 UTC

Return-Path: <christian@amsuess.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 6802C3A0DEE; Tue, 17 Nov 2020 02:07:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id otz9IFu7yq6c; Tue, 17 Nov 2020 02:07:15 -0800 (PST)
Received: from prometheus.amsuess.com (prometheus.amsuess.com []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6117E3A0DEF; Tue, 17 Nov 2020 02:07:10 -0800 (PST)
Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net []) by prometheus.amsuess.com (Postfix) with ESMTPS id 58E654083B; Tue, 17 Nov 2020 11:07:08 +0100 (CET)
Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 20400AB; Tue, 17 Nov 2020 11:07:04 +0100 (CET)
Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:f94e:4afb:3326:ba58]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 2991C180; Tue, 17 Nov 2020 11:07:03 +0100 (CET)
Received: (nullmailer pid 2871458 invoked by uid 1000); Tue, 17 Nov 2020 10:07:02 -0000
Date: Tue, 17 Nov 2020 11:07:02 +0100
From: Christian =?iso-8859-1?B?TS4gQW1z/HNz?= <christian@amsuess.com>
To: draft-tiloca-core-groupcomm-proxy@ietf.org
Cc: Core WG mailing list <core@ietf.org>
Message-ID: <20201117100702.GA2838739@hephaistos.amsuess.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="h31gzZEtNLTqOjlF"
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/Aoeiz7w0lv-unrnRgNjwFyOx_fY>
Subject: [core] Aligning groupcomm-proxy and mutlicast-notifications
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Nov 2020 10:07:18 -0000

Hello Marco and Esko,

from today's CoRE meeting I've seen that the Response-Forwarding option
has a similar structure as multicast-notifications' tp_info /
Listen-To-Multicast-Responses option.

Both share that they encode a host address (and possibly port) that
isn't typically a name but really an address, and that the underlying
protocol may not be fully understood by the client behind the proxy.

The latter is not in groupcomm-proxy as it is now, but may make sense:
All the client needs to know is that the host of the resource *is*
actually a multicast address, not how that precisely works. (It may even
take that information from somewhere else if the authority component is
a host name which the client can't resolve). What makes this a bit
tricky is that we don't have any other multicast-capable transport, but
I imagine we could have.

A related component that could play a role in the alignment is how the
address is then encoded when contacting the host directly through the
proxy. Unless the proxy is reverse (which is AFAIK not discussed at all,
and may be worth discussing on its own), if the client still wants to
use the proxy, it needs to set Proxy-Scheme: "coap" and Uri-Host:
"2001:db8::1" from the data received as srv_info =
[#6.260(h"20010db8...1")]. The information that goes into Proxy-Scheme
would currently be hardcoded; if something like multicast-notifications'
tp_info is used, that would be looked up from there. (Granted, when
follow-up requests are used, even a client that knows the tp_info is
mapped, but at least that could be an easy extension).

Anything we come up with here that works for both our use cases might
also be suitable for CRIs[1], which could then be a reusable component
in converting back and forth between (Proxy-Scheme, Uri-Host) and
something that contains binary IP addresses.


[1]: https://tools.ietf.org/html/draft-ietf-core-href-03

To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom