Re: [core] WG Last Call on draft-ietf-core-conditional-attributes
John Mattsson <john.mattsson@ericsson.com> Sat, 21 January 2023 09:06 UTC
Return-Path: <john.mattsson@ericsson.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 AD974C14CE51 for <core@ietfa.amsl.com>; Sat, 21 Jan 2023 01:06:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
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 JQX2-gosCjkh for <core@ietfa.amsl.com>; Sat, 21 Jan 2023 01:06:22 -0800 (PST)
Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-he1eur04on2082.outbound.protection.outlook.com [40.107.7.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93435C14CE2B for <core@ietf.org>; Sat, 21 Jan 2023 01:06:22 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fwjDcg6MHc5pmGnLmbUehbckOkr9Hxu5wkAfHcC4p0p+HVZe0IYKRaoN41hokP4h8mpwnrEVjh2LwxFvi/PVV0vUmVXZsEAEEHNpaQjTjD4qdwY/bz6zcKHQwKkuR5sODW5++OF0SUuF2dTpR+KwByxwOJ4FUnk1OnCXAN68wFdJO1DOLB3bHcA0zZp888/7VJdAMxhKvXWmYXx56PcRFnZSB093bRQBPW6Cofn9y3dqmuMEWGTVnjpS8LxqqKv2J1BEAe1kIyoNc2ZKJUlTvKpnmj0kM2SpFuxHs88nz5vublm5ehsxL72CzjKe9JTth9xJqwM/tHdPiTWzef22EA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Qq9Cie0rz45O8S9ZdZzot0poJ35I8DsCmqhKQg+dK88=; b=h24gi71AAYEnACIJP5T1jqe2zIpZ+jGn+wEfS2FEusoF7tSHrT9mOImufaTs7FH5sQZhGYTAKSiRucGvzTKYO1LUaf4NbvIdNMU+iokXPdmUUwtKXghSFbVDpX/nqeJdWJi4JHX2QHdIdUKfFoumKs5g2K28kxUuM+iiN7vVajhYJAvRskXBT7ac+RsUrbtAazeJ3v0DTrCHNJT6Ua4h01tEFTJwXhGahIzosPB9cUVddV+1SZVSee0sSJ/d1AbfaF+pxhodhPsY9xCJkBZuneX4m/ZFYoHErVysBwMz6+fWgHzi4oCJPjYNc9sox/955rpWxuxFl/h1ZHvq4KHR9A==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Qq9Cie0rz45O8S9ZdZzot0poJ35I8DsCmqhKQg+dK88=; b=PdY/1bVrIDKDR/z1BckiuZKPRjsJFyAQKBDsuS/zHKA+KYvapMS1rLc+YAEysxC2adxcVNicA4/1Eai2yqzpDHdPQp+4ZJ6T+oL2akaBGFoHe4KSAysc75vtut56vys9JY7DwEJbrWBw9UxbkhElDrZwhp7dGcFqeh5jwRjOMGE=
Received: from HE1PR0701MB3050.eurprd07.prod.outlook.com (2603:10a6:3:4b::8) by VI1PR07MB6670.eurprd07.prod.outlook.com (2603:10a6:800:18e::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6002.25; Sat, 21 Jan 2023 09:06:17 +0000
Received: from HE1PR0701MB3050.eurprd07.prod.outlook.com ([fe80::fc77:42d2:1bc6:ec49]) by HE1PR0701MB3050.eurprd07.prod.outlook.com ([fe80::fc77:42d2:1bc6:ec49%12]) with mapi id 15.20.6002.027; Sat, 21 Jan 2023 09:06:16 +0000
From: John Mattsson <john.mattsson@ericsson.com>
To: "core@ietf.org WG (core@ietf.org)" <core@ietf.org>
CC: Klaus Hartke <hartke@projectcool.de>
Thread-Topic: [core] WG Last Call on draft-ietf-core-conditional-attributes
Thread-Index: AQHYZU9W3g6tkPqHz0+ytynZfLYMrK6cgL+AgA2hbbU=
Date: Sat, 21 Jan 2023 09:06:16 +0000
Message-ID: <HE1PR0701MB30506B8112A4222EE6CE243789CA9@HE1PR0701MB3050.eurprd07.prod.outlook.com>
References: <5a8317ff-c7ff-ffda-da15-94bb04700451@ri.se> <CAAzbHvaqrM6v+Ls+MfVENAhxSWNdJbRFFbfeu+7-jT-uGFdwEg@mail.gmail.com>
In-Reply-To: <CAAzbHvaqrM6v+Ls+MfVENAhxSWNdJbRFFbfeu+7-jT-uGFdwEg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=ericsson.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: HE1PR0701MB3050:EE_|VI1PR07MB6670:EE_
x-ms-office365-filtering-correlation-id: 67af4382-58a6-4a23-1ba1-08dafb8ec0d8
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: MHk8iqVpWzIZJBcq45jlfsqpgUAaJPGe3XXVFksZuyfI/y++gRCFt/K1txqMe55mHrmMIPirYSlCy9AjTTaa3axsJbXT/aeYSij1qq5nMoQD9WgNWfbdM+konM6nPYk2hRxGpqoXfA7Y1zEsVUYhet9ZDkoJNKqqAMBiwPChRRyJKq6TLH/4wwIfoiOVtAXRWV7dgyWHCZtBE9l75VVM66O2H+MSsTYhXwG4pIRSmrJ0NY4qmIUZ3b7uKGHBwKO40qVaeIleAB7B1LVix5lOnub4D4Ic5k4ZDd37gXpkOG9xhT2hNojIk2QK5TLwrbq0W2dxZ+PsKqUNW2v0TIcDxEudSOo3WdaYXSFAZMXvJ3/T8gmHiPaQ8aZnKxR1WEZL3lFytnwex/ybMBujLc7Rg7Qd+xfaO5jmrmUhF4XTuJXc20c1ZdHV7Wh6SzaA+wV4sBcG7YIV+3BETeBdBTAcshKr5Xmahm3Ihf1ne3Ai8Jtup/i0jE7ahQe3Tj3JWqg49TJqF1Js36Tyfmvvjt+JNnPxlOUp+VHDuqdbgKkYi62GI+lvDebzyBnL+FZa0GA8LQR3ubn2Ly5uepy0qmtaZ1i/Fj6QaYwaUTHEhIE7ifcgAOajRjAn3xW7KCDinSY+FlaKJSTCE+HhidYf+ZXQaSwkvSHgrF3S02XHcM+00KwZm3lqKC/O6MY7E37AQV8wt5L8GuEUmOCBxYkLrsrFN7FtLDo4hSQ9fOvY+1U0AqY=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0701MB3050.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230022)(4636009)(396003)(366004)(136003)(346002)(39860400002)(376002)(451199015)(53546011)(38070700005)(7696005)(71200400001)(478600001)(9686003)(166002)(6506007)(966005)(186003)(26005)(316002)(44832011)(83380400001)(8676002)(66556008)(4326008)(6916009)(91956017)(76116006)(66946007)(66476007)(64756008)(86362001)(41300700001)(66446008)(8936002)(5660300002)(38100700002)(52536014)(82960400001)(33656002)(122000001)(55016003)(2906002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: /pdEhYNhqcS9P2IYQH78ETZui+s+x/X+zlXYxAZuhoXvLL/1iX7KhxFYa2HApOSxtYALRPKHeDr8i/0ODbK5AP7yTDsF36+2M82NhHGLPLP6Q+jaQ51Cepa/w6+g6Ns111CJSmjD0qTbzxhdRO0HVrb2b9EJ86w2RD6NbZ9U+XxJkB8EQmwV7qSIejYmvfWQv+EItcOxouPoTfQZrxrrdczqGUD9rZ9ymI9EDdQWu+GgFtMurLvxDRmzxVyP+M3Zyxu7E+rErwIiDtRC7Px6C13ed8U1gHnTgVbPiT2Em1IPRb8D0he6kgU2/FjmVdD4RYpmnblW/HJcw0KEKV0zqefDPaVP8jQsYkVptblg55JfbARktKV0ePrAxBXgw6rwbNhubPiCvKeVnG09tkYLqqauB7aUSZRtUMiTk6C7kMmz7ixGEe3KQoW/CYsD+jRwIr9KkWhQAYXkjCI/lrD9PWJblAPe2q6DAeLIj0pny/uQFO1LFkfHkoQzLF/X9J0euof9IAfKdaBew3HnWP8laZ0BEb56C0JJADD3sUJdemCbaJdTjLMClwvCC5EV/3zvsOk/lIWlmOh9gIgd98GpC2G4UqUCPf1ths9KgwyRU9HsP8bhntY+25UoCO2qn5NBbOjTRe/0z6NMkpWT4paLWyDgoBahfVA10pFSien4tfre86KNw4K4L7xni5zdNbbM2rGmyT/RYXl+yr1u0gtOze06239p8rI4NWwNkXFpnbtiJSEPaytR403BuYpMZEuhm67ozQqHOE/wtUMa4YfihkhVgfDhYgO4HtfqWhwJ9JK0Qxe7pmFKfo7nYv2O7ucZ+LeibvjiEvp0XgiKoLZLOHR6xu8MtsRnMXTl4JZ5Zx3D6JIt4BvTsFU3Fz/LI6LPygXlianslqZ8M0ko2ASTWa6gnKProNLluylVP7xnZpzsDSKWKn0PJkfJK10+bTcDxaHqg89myxNYKJTNQavrjce4IDntNyNQPYoUFlhyfKMp+4nOxvn5hnLmdbZG86MIcGYbSa1OevDoTF6/x/miT9vPVWWLq97p9cC/T/oq725xJLxMtfwySsMxQmXpZx5OI7AifsAFWv0FySiwrQkhZLSseoKjmDm8PbEvoI0QStYw0mLLozFxzuIlWcEf6A7/0VQdQZ96Eg5/s9TyCN+wttsqytBXDdeLNDWkl2Tn0CN2YSkhmKSTYFh7jJXOJ68tu8fgjK3Mcn7/8c7g2wAQZYYsD/adYvLOahA8ujql4D+HkEelgac5DILB9OgbnQnpHrpRGr7Yd2P5RxRO1QTYfLcOjVQYvxS8KqGgwHTkRn0L8OS9NDsD0C6aIhKj/6lINdZmlyPi4Z3RcB+pCAPHl037XobaHWwLitMTv7aawYj5dakHzEpvR+YfwDUbYAcyQqldwgNGRiGpZ7O31ZriXEK2HaHSYXnLorePj4PLjVo2/GrhI7aichwfaUUy/3UWUnI2XneQifAm1yMpIzVU7QwpOS6ijAM+52a1Lu+m7ejxlR1VYXBfhoXEoHI980UpcIUnOx/nPf4uqm+TOYpXu4WvnJgw13jPYvhDIfLDiZ3Ajxz61O2d7L42faE/qovXdwvbQT/RJuJh9HxEOUd/xPI2xUjgisclRSRjlI852+I=
Content-Type: multipart/alternative; boundary="_000_HE1PR0701MB30506B8112A4222EE6CE243789CA9HE1PR0701MB3050_"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: HE1PR0701MB3050.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 67af4382-58a6-4a23-1ba1-08dafb8ec0d8
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jan 2023 09:06:16.5350 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: bOTw6l4aaPv5TX1DvFpviLmOAWciVx9faNjxf21iIlzb7P/pojUOdPqVx5TgZujO+n4aMgeNGr9lEoKTPoQz1cmsnGy1ncWN5IEEsssZuBA=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB6670
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/Yu-3Wtj-AoHOKO3qIB58r2Lb1GE>
Subject: Re: [core] WG Last Call on draft-ietf-core-conditional-attributes
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: Sat, 21 Jan 2023 09:06:27 -0000
I think these are very good points that the document needs to address. Some high level comments: - What is a resource? My understanding is that that there is a one-to-one mapping between resource and URI. When you add a query parameter like the conditional attributes you get a new resource separate from the from the a similar URI without query paramers. - I think it is good distinguing between discrete and continuous quantities. A discrete quantity like “version number” or “the number of people at the CORE WG meeting” only changes at specific points in time. Continuous physical quantities like “CO2 level in CORE WG meeting room” changes every time you measure if you measure with high enough resolution. For continuous quantities, the state changes are a bit arbitrary, it just depends on how often you measure. Letting the client influence if it wants to get less or more notifications seems like something worth doing in some form. Cheers, John From: core <core-bounces@ietf.org> on behalf of Klaus Hartke <hartke@projectcool.de> Date: Thursday, 12 January 2023 at 17:49 To: core@ietf.org WG (core@ietf.org) <core@ietf.org> Subject: Re: [core] WG Last Call on draft-ietf-core-conditional-attributes Hi all, here is my review of draft-ietf-core-conditional-attributes-05. The draft presents a protocol extension of "Observing Resources in CoAP" [RFC7641]. RFC7641 is itself a protocol extension of CoAP [RFC7252], which enables a CoAP client to retrieve the state of a resource at a CoAP server (in the form of a resource state representation) and to keep this retrieved state in sync with the actual state at the server. The semantics of this mechanism are pretty much the same as polling the source, but behaves more efficiently by using a notification mechanism under the hood where the server chooses the best strategy under the principle of eventual consistency ("If the resource does not undergo a new change in state, eventually all registered observers will have a current representation of the latest resource state.") According to itself, "Conditional Attributes for Constrained RESTful Environments" [draft-ietf-core-conditional-attributes-05] aims to give clients more fine-grained control over how the server generates notifications. To make it short, this aim is fundamentally at odds with how RFC7641 works: The notification mechanism in RFC7641 is a protocol detail that operates under the hood to provide the functionality of keeping the retrieved resource state in sync with actual resource state. The Conditional Attributes defined by the draft interfere with the generation of notifications, so that this functionality is in its generality no longer given: The client no longer receives a representation of the actual resource state through the notifications. I therefore believe that this draft should not become an RFC in its current form. However, I think that the draft actually just got the formulation of its aim wrong. Rather than interfering with under what conditions and in what way the server generates notifications, the draft should define how the server updates resource state and how the client can influence this. A simple good way is resource state projection. For example, if the state is a numeric value, it is possible to project a new state from the resource state using e.g. the min or max function. This new state can then be observed by the client. And the best way for the client to let the server project the resource state in this way is to parameterize the resource with a query string. A possible Conditional Attribute could therefore be "max=X". This makes the observed resource state the result of the calculation max(X,Y) where X is the query string value and Y is the actual resource state. Another way is that the server doesn't even change the state of the resource unless certain condition(s) are met. For example, whenever the server wants to change the state of a resource with a numeric value, it compares the new value to the old one, and it skips changing state if the difference doesn't exceed a threshold. This threshold value can also be specified by a client using a query string. This results in exactly the same behavior as some of the existing attributes, just not in terms of sending notifications but changing resource state! Overall I think it would be straightforward to redefine almost all attributes in one of these two ways. An exception is an attribute like pmax, which makes a server send notifications that it wouldn't have to send with RFC7641. Such a change in protocol cannot be achieved by changing the way resource states are updated. Instead, the draft should describe it for what it is: a protocol extension. And for protocol extensions, we use options in CoAP. Best regards, Klaus _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core
- [core] WG Last Call on draft-ietf-core-conditiona… Marco Tiloca
- Re: [core] WG Last Call on draft-ietf-core-condit… Marco Tiloca
- Re: [core] WG Last Call on draft-ietf-core-condit… Klaus Hartke
- Re: [core] WG Last Call on draft-ietf-core-condit… John Mattsson
- Re: [core] WG Last Call on draft-ietf-core-condit… John Mattsson
- Re: [core] WG Last Call on draft-ietf-core-condit… Christian Amsüss