[core] Review of draft-ietf-core-coap-pubsub-09

"Damm, Benjamin" <Benjamin.Damm@itron.com> Tue, 29 October 2019 20:05 UTC

Return-Path: <Benjamin.Damm@itron.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 099F11200A3 for <core@ietfa.amsl.com>; Tue, 29 Oct 2019 13:05:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=itron.com
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 O2XXFfM__3rm for <core@ietfa.amsl.com>; Tue, 29 Oct 2019 13:05:41 -0700 (PDT)
Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-eopbgr800080.outbound.protection.outlook.com [40.107.80.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C144120119 for <core@ietf.org>; Tue, 29 Oct 2019 13:05:41 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IM+mfuC2MX1RlqBJmoWk2tPGJM+jNCrG2E8uogs8yvfe9Ug5SyW10uBFTytxovFqsg9b0lDFwEf6TL647FHGSb6f7r6nPnMsSJOG9FnDcOuVoztWq0T5w7mo5LuQCB0bWr2nOYecGID8rZ1joEWYL3GQK6hE9gNwxBpAbwAV8rszbkrAQLBMHLxv2SKF9zFDGYp6l05tvd2UkH+f0BFnXtrgQrJtEaHi+tLH4uiIj/ZA0Jv58jXFwHMzSdwJFRZ9GDC98sOkex92hfL11IuzcfIdxKjFlkZ8bIQmTugYt+2jc904Wa+pf/gB3dbpj0maJlkkWPVmXXdisc2yoWwOdw==
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-SenderADCheck; bh=eXKfRuumcLTkbbnULsTcxpd/rUUZhRdEDIJvxM9XEg0=; b=FSG+c8C8Y0hHnLx/PDxE4bZFPADE0mGKaxlYWnUabX0472tksK2ZB1SCcQOPrS/CiEwILswDmg+o5jwTRrYsD8J2dYpLyB7x8xCYhkzDbWlnzoaF/fEBZ56t1OQVE+rGG3SvwaUNKBsgxaqPi1tyyzZYtlQsECBkGf446mr1AlLT1nhb9mgygY8nUTlD78+oI6wNOLBAfek77KoG2f897w5tSXu88LUlsidd3QDb71K9VZS5d97Rg1tPk+bLK5FWycl7aSoeF/nDaYYaVwuVZYzI/i1garGkiqYVBRG5vaHBSZze84jXAcX4iZRtruwL6Oe3tQaoqmqfQ/j+cxOfHg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=itron.com; dmarc=pass action=none header.from=itron.com; dkim=pass header.d=itron.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itron.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=eXKfRuumcLTkbbnULsTcxpd/rUUZhRdEDIJvxM9XEg0=; b=MzPgK48iDb5Yf/JqcrzGkCOe134bpRGOhIP78psgGzhNx1EdpWvRw/q4COm23Bwp6qKqeGB8omJO0nl0MJY1EY0KRtlw/fi+CPxKLHCjEX9vw2PUbOHEf5m1PwqtBiQjoJ2sfmCFjpaTZ2BIwRQcnT+l7RSmELX2iZwo1CaWOo8=
Received: from BY5PR04MB6772.namprd04.prod.outlook.com (10.186.135.146) by BY5PR04MB7106.namprd04.prod.outlook.com (10.186.132.201) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2387.20; Tue, 29 Oct 2019 20:05:37 +0000
Received: from BY5PR04MB6772.namprd04.prod.outlook.com ([fe80::e43b:18ed:1236:594e]) by BY5PR04MB6772.namprd04.prod.outlook.com ([fe80::e43b:18ed:1236:594e%6]) with mapi id 15.20.2387.023; Tue, 29 Oct 2019 20:05:37 +0000
From: "Damm, Benjamin" <Benjamin.Damm@itron.com>
To: "core@ietf.org" <core@ietf.org>
Thread-Topic: Review of draft-ietf-core-coap-pubsub-09
Thread-Index: AQHVjpQ7R0BpYPvt5Uy0mvErbSZRpw==
Date: Tue, 29 Oct 2019 20:05:37 +0000
Message-ID: <06A853EF-D9F0-475D-8E66-29C2A077B154@itron.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Benjamin.Damm@itron.com;
x-originating-ip: [74.39.163.71]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 368da053-7bb1-4fdc-b06c-08d75cab5d97
x-ms-traffictypediagnostic: BY5PR04MB7106:
x-microsoft-antispam-prvs: <BY5PR04MB71068376D23F6B565286D5C2F8610@BY5PR04MB7106.namprd04.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0205EDCD76
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(366004)(396003)(346002)(39860400002)(136003)(199004)(189003)(6916009)(66476007)(14454004)(91956017)(26005)(33656002)(81156014)(76116006)(1730700003)(66946007)(25786009)(81166006)(66556008)(36756003)(2351001)(66446008)(8676002)(64756008)(2906002)(6506007)(476003)(2616005)(3846002)(316002)(6116002)(7736002)(71200400001)(186003)(256004)(71190400001)(6436002)(6486002)(86362001)(2501003)(305945005)(102836004)(478600001)(8936002)(5660300002)(99286004)(6512007)(486006)(66066001)(5640700003)(14444005); DIR:OUT; SFP:1101; SCL:1; SRVR:BY5PR04MB7106; H:BY5PR04MB6772.namprd04.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: itron.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: dHnWoGwhbeBnzLEN/BoVZD/TWBjmOUw3IKynCGIvpZ3p6z4j1vlHmkzSpFejLgmdY2YyZEsjva8nIJQuh/4JfJG9L5qNBHp+KexKHA+1fnUZqVnaLpVlpMNxusT6XnkvdBRcD+otKE64mXsSlo3Z+gzhAbYVeuVa8OtHsvHNoQ0SYTKzadSVvHlAb7DxqdGwgRVo8HFLy7W13Tq0VjtJoxqejozQ/uQaOBFDGbtB56Sr9iocgtKQDMKSDwfAZasu6pgOks/1S9ncfikAzz2uTFFCyFpwkBHclsNCCNSVwaeWqJEXBWeFCVUVjIhbc0Fld6wFWzAFJPJfb9INHs6sx3ibNeIcFlv9gIWMDrySYkdmhR/3y6cO5taF9bMEQpUBDBUobge8VT+//2tkmX50td95dI4nxdw7GUIyIwLnae9Ov/rRDYRkPAJScLOEKcKA
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <8F55997A97BCB645AFA997464D179669@namprd04.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: itron.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 368da053-7bb1-4fdc-b06c-08d75cab5d97
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Oct 2019 20:05:37.3698 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5818bd20-bf25-47b1-b996-d419d7e6e8ba
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: exloIwVdT6y3Mh+sdP/d3f8KpAcrusJD/ZW4G6ENZlAEKXAFAVsGMy2kdrjOR6RM
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR04MB7106
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/wshviFckFyOo3HbqhabAFy40Ug8>
Subject: [core] Review of draft-ietf-core-coap-pubsub-09
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, 29 Oct 2019 20:05:43 -0000

Hello Core,

I've reviewed draft-ietf-core-coap-pubsub-09.
I have nits, but the largest areas of concern for me are these:

* Creation of topics as a long-lived resource is throughout the protocol. Coupled with other restrictions in the protocol this makes large topic trees with fine-grained topics infeasible, such as having a MAC addresses, IP addresses, UUIDs, or hash values as entries in the topic tree. A topic tree such as "{tenant-id}/{device-mac}/{event-id}" would be a valid pub-sub topic tree, but in this protocol it is all but impossible, and certainly impossible to do efficiently. Assume there are dozens of tenants, millions of device MACs and a hundred event IDs. 
* The protocol allows for single-shot topic creation and publishing in one message, but doesn't allow subscribing to topics that don't "exist", leaving a race condition or at least additional probes by the subscribers to see if certain topics of interest exist. Presumably if a subscriber wishes to subscribe to a topic that doesn't yet have any messages, the subscriber could create the topic, but then authorization of topic creation becomes an interesting thing. The state diagram for correctly subscribing to a topic that may not exist yet is at least three states large.
* The protocol requires the broker to cache the most recent message on all topics. This greatly expands the footprint of a broker, because it must hang on to at least one message per topic. Message retention should be optional.
* Max-Age is only used to communicate topic time to expire. Instead, it could be used to indicate age of the message, or the time which the message should be considered still fresh, both of which would be better uses.
* There is no way to subscribe to multiple topics with a single subscription, nor is there any way to subscribe to an entire sub-tree.
* There is no way to subscribe to any subset of the topic tree.
* Protocol is ambiguous regarding whether topics that are also parent topics can themselves be topics.
* Protocol is ambiguous regarding message delivery semantics; can messages be delivered more than once? Maybe. Forcing messages to only be delivered exactly once is a higher burden of reliability than merely ensuring messages are delivered at least once, so I am not suggesting that the protocol be limited to only exactly-once semantics.
* DTLS client certificate is the only option for authentication, and there's no profile defined for how this is done. Thus there is no defined way to have an interoperable authentication scheme.

I was hoping that the coap pub-sub protocol would be viable for a head-end collector (of sensor readings) and distributor (to head-end clients and to field clients) for large networks with millions of sensors but with the definition of the protocol as it is currently, I cannot see using it that way.

Regards,
-Ben