Re: [core] RFC 7252 - 8.2 - Multicast - Request / Response Layer, page 67, top

Jim Schaad <ietf@augustcellars.com> Tue, 31 March 2020 16:52 UTC

Return-Path: <ietf@augustcellars.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B37083A241F for <core@ietfa.amsl.com>; Tue, 31 Mar 2020 09:52:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level:
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LKsyM8w-GW3J for <core@ietfa.amsl.com>; Tue, 31 Mar 2020 09:52:12 -0700 (PDT)
Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4762A3A241D for <core@ietf.org>; Tue, 31 Mar 2020 09:52:12 -0700 (PDT)
Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 31 Mar 2020 09:52:04 -0700
From: Jim Schaad <ietf@augustcellars.com>
To: 'Klaus Hartke' <hartke@projectcool.de>, 'Esko Dijk' <esko.dijk@iotconsultancy.nl>
CC: 'Achim Kraus' <achimkraus@gmx.net>, <core@ietf.org>
References: <580bb0f4-89c4-2d11-b17b-520ddfe89c33@gmx.net> <000501d60452$c96cfa00$5c46ee00$@augustcellars.com> <1e74313a-d258-622f-d43e-ff1fa8f7d06d@gmx.net> <AM5P190MB027536259A44102F7AB9E058FDC80@AM5P190MB0275.EURP190.PROD.OUTLOOK.COM> <CAAzbHvbeEyws+wVchovoVTK=WutWoHCNcfv8LrpxmshLxJ_w+Q@mail.gmail.com>
In-Reply-To: <CAAzbHvbeEyws+wVchovoVTK=WutWoHCNcfv8LrpxmshLxJ_w+Q@mail.gmail.com>
Date: Tue, 31 Mar 2020 09:52:02 -0700
Message-ID: <011301d6077c$b5d347b0$2179d710$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQIXVeiVC1e4HIxpxUNqDgp/ppWwxwLeBdy3AlRjDEICXv5oEAIsRnhBp5JfwQA=
Content-Language: en-us
X-Originating-IP: [73.180.8.170]
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/gQ3Mblo57LeELif-bzFW6MxyJjU>
Subject: Re: [core] RFC 7252 - 8.2 - Multicast - Request / Response Layer, page 67, top
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, 31 Mar 2020 16:52:15 -0000


-----Original Message-----
From: Klaus Hartke <hartke@projectcool.de> 
Sent: Tuesday, March 31, 2020 4:46 AM
To: Esko Dijk <esko.dijk@iotconsultancy.nl>
Cc: Achim Kraus <achimkraus@gmx.net>et>; Jim Schaad <ietf@augustcellars.com>om>; core@ietf.org
Subject: Re: [core] RFC 7252 - 8.2 - Multicast - Request / Response Layer, page 67, top

Esko Dijk wrote:
> However CoAP does define that a Server responds from the same endpoint that received the request, I believe. See below text quotes and analysis.

Yes. In the simple CoAP-over-UDP unicast NoSec case, if a request message is sent from an endpoint 192.168.0.1:54321 ("client") to an endpoint 192.168.0.100:5683 ("server"), the response message must be sent from the endpoint 192.168.0.100:5683 to the endpoint 192.168.0.1:54321.

The response message cannot be sent from any other endpoint, because then the client couldn't match the incoming message to its pending request (it would appear to come from a different server). The response message also cannot be sent to any other endpoint, because then the client wouldn't get the message (it would be sent to a different client).

I view multicast messages basically like e-mail mailing lists. E.g.
(IMO): A request message is sent from the endpoint 192.168.0.1:54321 to the special endpoint 224.0.1.187:9999, the message magically shows up as incoming message at the endpoint 192.168.0.100:5683, and the response message must be sent from the endpoint 192.168.0.100:5683 to the endpoint 192.168.0.1:54321.

[JLS] What he said.  And then after the first message comes in from 192.168.0.100:5683, all of the messages from that endpoint are correlated together so that you can do things like blockwise.

Klaus