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

From: "Damm, Benjamin" <[email-masked]>
Date: Tue, 29 Oct 2019 20:05:37 +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