[core] Review of draft-koster-core-coap-pubsub-05

[Jim Schaad <[e-mail]>]

I have a hard time saying that this is ready to be published, but that is in
part because I think that the security aspects that are not being addressed
in the document are important.


Section 3.2 - The phrase "and potentially buffer messages" is causing me
problems.  By definition it must buffer the last data value that it
includes.  It would be good at this point to explain exactly why it is
buffering messages here.  I assume that you are talking about the flow
control issues that are discussed later but I don't know this.

Section 4.2 - What is the behavior of Max-Age for sub-topics?  Is the topic
deleted only if it has no current sub-topics?  Publish rates of the topic
and sub-topic may not be the same.

Section 4.2 - How does a topic creator control who can a) publish to the
topic, b) create sub-topics, c) subscribe to the topic.  Based on how things
are laid out I make the assumption that the broker is the entity that would
enforce these rules.

Section 4.3 - As we go forward into the world of having secure items, the
rule on only publishing a fixed content type means that there will be no way
for a broker to create other content types without losing the authentication
source of a signature by the publisher on the content.  It would be nice if
it were possible to publish multiple content types at one point.   I guess
one method might be to look at a content type that would be list of contents
w/ different content types but then the discovery method becomes odd.  Also
create would need to be modified to deal with the situation as well.

Section 4.7 - The following language is driving me crazy.  "A CoAP pubsub
Client wishing to remove a topic MAY use the CoAP Delete operation".   If
you are going to say that it may do X, then you need to also say that what
other things it could do to remove it.  I think you should just remove the
MAY here (and in similar places) and just say "to remove a topic uses the
CoAP Delete operation".

Section 7 - Should there be advice on how to distinguish between a new
publish and a re-publish because a response was not received?

Section 8 - DTLS will not provide authentication if there is a proxy in the
way between the client and the broker that terminates the DTLS session.
(The whole hop authentication vs end-to-end.)

Section 8 - the last paragraph is giving me a problem.  It appears to say
that if the broker is not trusted hen it would have a problem doing the
correct forwarding to subscribers since it would be unable to read the CoAP
headers.  Is that correct?

Confirmation of messages.  The system seems to be very light on telling one
when confirmation of messages should be used and when it should not be used.
For example, if notifications are being sent out from a broker - should all
messages get confirmations before continuing, should only some messges get
confirmations based either on the message published or on the notification
that is being sent to the client.  I.e. do you treat a removal from a
subscription differently if it is deleted vs if the authorization for the
subscriber expires?  In one case doing the get will show that it no longer
exists but in the other case the client will have missed messages when it
was not subscribed.

Jim