Subject: [core] pub sub in coap

From: peter van der Stok <[email-masked]>
Date: Wed, 19 Nov 2014 15:09:36 +0100

Hi Michael,

Thanks for the renamed sleepy node document. In the context of sleepy 
nodes this may become an important document. I do have questions and 
remarks to improve my understanding of the document.

I would suggest that you change the title to “PubSuB broker in CoAP”, 
because the document does not treat publish subscribe but a broker using 
the publish subscribe paradigm. In the abstract, phrase 2, I would 
suggest that you write: This document specifies a publish-subscribe 
broker for CoAP that …

Throughout the document:
Can you explain the difference between a client endpoint, a client mode 
endpoint, a client role endpoint and a client mode EP. Same for the 
server. If they are identical I suggest to use only two terms: client 
endpoint and server endpoint.

Section 2:
In additional terminology I would prefer PubSub broker service, PubSub 
broker Function Set, PubSub broker endpoint.
The concept of topic is difficult to grasp. I understood from the later 
text that the topic is just an identifier that MAY be associated with a 
resource. (I don’t understand the reference to an object)

In figure 1 the purpose of the Web client app is not clear to me. I 
don’t find any reference to it elsewhere in the text. I concluded that 
it is identical to a client endpoint.

In section 3.2 I don’t understand the restriction to actuators. You 
write that an endpoint SHOULD update the RD regularly; that is a bit 
difficult for a sleepy endpoint. What does “not directly reachable” 
mean? That communication takes more than 1 hop?

At the end of section 3.3 I did not understand what the client role and 
the server role mean. In section 3.3 I understand that the broker as 
client updates the server, or the broker as client observes the server. 
Probably I am missing something essential here.

Section 3.4, I don’t understand how a topic identifies an object? Is 
object used as a template which may have many instances? Does that mean 
the object defines the structure of the data contained in the resource? 
I don’t understand the significance of the object concept. I would 
suggest to remove any reference to objects.

Section 4. Figure 2 shows that there is a CoAP pubsub broker at location 
/pubsub. Does the example imply that pubsub brokers must be present on 
the rd? Is it possible to return other location names than /pubsub ? Can 
the RD “context” be used?

You write that in fig 2 the endpoint registers topics. Do I understand 
that /0/xx is a topic? That seems to indicate that topic is identical to 
a resource path on the broker.

In section 5.1 and 5.2 my confusion about client end-point and 
server-endpoint can be explained. I understood that a broker supports 
both client and server end-points. In fig 4, 5, and 6 the EP is the 
client endpoint and the broker is the server end-point. Figs 7, 8, and 9 
seem to be identical but for the fact that EP is the server endpoint and 
broker is the client end-point. May be there is no need to talk about 
broker or broker-user when explaining the client end-point and the 
server-endpoint function sets. I suggest to first explain the client and 
server function sets (figs 4, 5, and 6). A later section can show how 
this is used with a broker (present on rd or elsewhere) and the broker 
user (sensor, actuator, ..)

Hope this helps to clarify the text (at least for me).

Greetings,
Peter

-- 
Peter van der Stok
mailto: [email-masked]
www: www.vanderstok.org