Re: [core] Review of draft-bormann-core-responses-01

Carsten Bormann <cabo@tzi.org> Wed, 21 June 2023 11:51 UTC

Return-Path: <cabo@tzi.org>
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 F0FFCC151543 for <core@ietfa.amsl.com>; Wed, 21 Jun 2023 04:51:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w7RmU1rYMYhe for <core@ietfa.amsl.com>; Wed, 21 Jun 2023 04:51:42 -0700 (PDT)
Received: from smtp.zfn.uni-bremen.de (smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B6A1C15153C for <core@ietf.org>; Wed, 21 Jun 2023 04:51:40 -0700 (PDT)
Received: from [192.168.217.124] (p548dc15c.dip0.t-ipconnect.de [84.141.193.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4QmMKk3GJBzDCfh; Wed, 21 Jun 2023 13:51:38 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <448b8751-5823-a911-662a-bd9d1131261b@ri.se>
Date: Wed, 21 Jun 2023 13:51:38 +0200
Cc: "core@ietf.org" <core@ietf.org>
X-Mao-Original-Outgoing-Id: 709041098.08815-6b63a2f8ec0804eb66648d8cd9b70abb
Content-Transfer-Encoding: quoted-printable
Message-Id: <73631615-0B4C-49E3-8735-62A8234B8D93@tzi.org>
References: <448b8751-5823-a911-662a-bd9d1131261b@ri.se>
To: Marco Tiloca <marco.tiloca=40ri.se@dmarc.ietf.org>
X-Mailer: Apple Mail (2.3608.120.23.2.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/yzmH_TsBtdPyZxlHovjmXXzvk9I>
Subject: Re: [core] Review of draft-bormann-core-responses-01
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.39
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: Wed, 21 Jun 2023 11:51:45 -0000

Hi Marco,

thank you for this detailed review!
I think we’ll need some time to digest this.

I have started pushing in the smaller observations (and some that derive from it) into https://github.com/core-wg/core-responses

I have one terminology issue that probably just needs one new term:

> [Section 2.2]
> 
> * "One way to do that is to exchange a "phantom request", which is a request that client and server will agree to have sent and received, respectively, without it actually being sent between those endpoints."
> 
>    Basically, the "phantom request" referred here (and used in -core-observe-multicast-notifications) is an example of "configured request" as defined in this document. Correct? If so, it's worth mentioning.
>    
>    It is also consistent with the first paragraph of Section 4.2.

I’m no longer sure that using “configured” for any kind of non-traditional transmittal of a request works so well.
Maybe we want to have another word that takes the current definition of “configured” (i.e., non-traditionally transmitted) and use the word instead for cases where the non-traditionally transmitted request actually has some persistence in the configuration of the server.

Another potential improvement to terminology:

> [Section 2]
[…]
> * "Some established responses (observations defined in [RFC7641], and multicast responses in [I-D.ietf-core-groupcomm-bis]) match ..."
> 
>    I think you mean "and responses to multicast requests in [I-D.ietf-core-groupcomm-bis]) match ..." . Multicast responses are not part of that document and are rather used in -core-observe-multicast-notifications.

This indeed has a quick fix:
-and multicast responses in {{?I-D.ietf-core-groupcomm-bis}})
+and responses to multicast requests in {{?I-D.ietf-core-groupcomm-bis}})

We probably need to be a bit more conspicuous in distinguishing “multicast response” from “response to a multicast request”, maybe we need to create a more specific term for multicast response.

Looking forward to discussing this further this afternoon…

Grüße, Carsten