[core] pubsub draft review

[Peter van der Stok <[e-mail]>]

Hi Michael,

below my review of the pubsub draft.
My main focus was the alignment with RD draft, internal terminology and
alignment with pubsub security draft.
Please do not hesitate to question my suggestions.

Hope this helps,

Greetings,

peter
__________________________________________________________________________________
Review of PubSub broker for coap 

Section 2, Publish-Subscribe: 

OLD:
The publishers do not (need to) know where the message will be
eventually sent: the publications and subscriptions are matched by a
Broker and publications are delivered by the Broker to subscribed
receivers. 

NEW:
The publishers do not (need to) know where the message will be
eventually sent: the publication-messages and subscription-messages are
matched by a Broker and publication-messages are delivered by the Broker
to subscribed receivers. 

OLD:
CoAP pub/sub Broker:  A server node capable of receiving messages
(publications) from and sending messages to other nodes, and able to
match subscriptions and publications in order to route messages to the
right destinations. 

NEW:
CoAP pub/sub Broker:  A server node capable of receiving
publication-messages and subscription-messages and sending
publication-messages to subscribing nodes, and able to match
subscription-messages and publication-messages to route messages to the
right destinations. 

What are notifications? They appear more often in the text. Are they
observe messages? If so, introduce that in this section 

OLD:
Topic:  A unique identifier for a particular item being published and/or
subscribed to. 

NEW:
Topic:  A unique message-identifier to match publication-messages and
subscription-messages. 

Section 3.2
/clients to use to/clients to/ 

Section 3.3
Why introduce data-sinks and data sources. Not used anywhere else.
Suggestion rephrase section 3.3 with other already introduced
terminology. 

Section 3.4 

The representation text is not very clear; do you mean: 

"The links of every topic are represented according to one or multiple
content-formats" 

A suggestion to rephrase the topic name space:
The topic name space is structured as a tree expressed as a resource
path. The topic hierarchy is structured identically to the hierarchy of
the URI path. 

Section 3.5 I don't understand. I do see brokers in Figure 2. How are
they different from Figure 1? The location? IF yes, please clarify. 

Section 4.1 

/the link relation rt=core.ps/the resource type value rt=core.ps/ 

2nd al: …. a topic discovery entry point, called DISCOVER,…. 

Can figures 3 and 4 be moved up the text? 

Please use rt=ps.temperature instead of rt=temperature 

Everywhere: .well-known/core -> /.well-known/core 

Page 7: 

/{create}/{{create}} 

/limit amount/limit the amount/ 

OLD:
The client can then perform discovery for the parent topics it wants to
discover the sub-topics. 

NEW:
The client can choose to discover the sub-topics from the discovered
topic list. 

Everywhere: 

In URI template variable; please use same terminology and constraints as
for RD. 

For example, /ps cannot be prescribed. It should be an example value
used in the draft. 

Content-format: here only one is specified, where later in the text, and
earlier multiple content-formats are allowed. 

"Success 2.05: SHOULD use the value /ps"; NO, Never SHOULD. /ps is an
example path. 

Fig 3-5 two cts are allowed here?? 

4.2 Create:
/the target of the link/the reference of the link/ 

/for publishes to the topic/ to represent the topic links/ 

Page 9: 

"If a topic .. Figure 7"; I don't understand this sentence. 

/Ony one/Only one/ 

/used in the link target/ used in the URI reference of the link// 

/exactly one content format/at least one content format/ 

unless I have not understood anything earlier. 

/publishes to the topic/receiving any publication-messages for this
topic/ 

/elided/not present/ ; elide is an action not a state. 

".. with a target of an existing topic"; Don't understand this phrase. 

4.3 PUBLISH 

"PUBLISH to topics on the broker" This is new not-introduced
terminology; please continue with terminology of section 2. 

Concerning the paragraph: "A Broker MUST .. PUT requests": 

- Links are replaced not representations. 

- What is "resolution of notifications"? 

Page 12: do the figure 9 and 10 references in the text match the
figures? 

Figure 8 and 9 Do "1033.3" represent the payload? Please explain. Does
not follow from the template. 

Fig 10: no value in return of GET? 

Page 16: It only becomes clear now that the observe numbers 0, 1, etc
have a meaning. It would be beneficial to explain that earlier with a
table. 

4.7 REMOVE; Is there a restriction on removal, like only the creating
client can remove the topics it has created. To be enforced with PubSub
security. 

Page19: 

OLD:
A client which registers pub/sub Topics with an RD MUST use the context
relation(con) [I-D.ietf-core-resource-directory] to indicate that the
context of the registered links is the pub/sub Broker. 

NEW:
A client which registers pub/sub Topics with an RD MUST use the
Registration Base URI parameter (base=)
[I-D.ietf-core-resource-directory] to indicate that the Registration
Base URI of the registered links is the pub/sub Broker. 

OLD:
A CoAP pub/sub Broker may alternatively register links to its topics to
a Resource Directory by triggering the RD to retrieve it's links from
.well-known/core.  

NEW:
A CoAP pub/sub Broker may alternatively use "Simple Registration",
section 5.3.1. of [I-D.ietf-core-resource-directory], by triggering the
RD to retrieve it's links from its resource /.well-known/core. 

Remove: "the pub/sub broker triggers .. further details" 

6 Sleep-Wake operation  

I assume this section is about sleepy nodes and how to handle them. 

I don't think the statement that the broker keeps the state is correct.
The Broker keeps publication messages which contain part of the state.
Combining multiple messages about different topics from the same sleepy
node may reconstitute the state. I recommend to change this section and
write that for sleepy nodes it is recommended that a sleepy node
provides only one topic that covers the whole state of the sleepy node. 

The draft should also point out that the update of the sleepy node or
its reconfiguration is not covered. 

7 Simple flow control 

/publish messages/publication messages/ 

8 security considerations 

I don't think that end-to-end security solves your problems of the
second paragraph; You also need Proof of possession. 

I don't understand the last paragraph: "Depending on the level .. to the
subscribers". 

I am missing security objectives; see an example described in appendix
A.2 of core-oscore-groupcomm. Once these objectives are described, it
can be verified in pubsub-profile draft that they are realized. For
example, I don't see any statement about which clients are authorized to
delete topics. 

Probably section 6 followed by section 6.1 in ace-coap-pubsub-profile is
closest to what is needed, but with much more pubsub functional details.

-- 
Peter van der Stok
vanderstok consultancy
mailto: [e-mail], [e-mail]
www: www.vanderstok.org [1]
tel NL: [phone]     F: [phone] 

Links:
------
[1] http://www.vanderstok.org