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

From: Jim Schaad <[email-masked]>
Date: Wed, 3 Aug 2016 20:35:10 -0700

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 11 Aug 2016 10:16:03 +0200

Hi Jim,

let me share my views on this document.

> control issues that are discussed later but I don't know this.

The reason why the pub/sub broker buffers messages is because the IoT
device is sleeping most of the time. For that reason, it cannot always
forward requests from applications immediately.

This is functionality called 'queue mode' in LWM2M and other terms have
been used in other IETF documents.

In my review I have been wondering why we aren't re-using the concepts
from LWM2M here.

Regarding the "topics": I have read this a bit differently. For me, a
node has resources and it publishes those. Then, there are applications
(Web applications, smart phone apps) who sent requests for those
resources. These resources have to be identified somehow and in LWM2M
there is a specific way of addressing the standardized resources (and
objects), as described in
https://www.iab.org/wp-content/IAB-uploads/2016/03/ipso-paper.pdf. Maybe
you want to be more generic here but I think it is important that there
is a standardized structure here and that we are not only talking in the
style of MQTT topics.

Ciao
Hannes

---

From: Jim Schaad <[email-masked]>
Date: Thu, 11 Aug 2016 08:22:08 -0700

> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email-masked]]
> Sent: Thursday, August 11, 2016 1:16 AM
> To: Jim Schaad <[email-masked]>; draft-koster-core-coap-
> [email-masked]; [email-masked]
> Subject: Re: [core] Review of draft-koster-core-coap-pubsub-05
> 
> Hi Jim,
> 
> > 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
device
> is sleeping most of the time. For that reason, it cannot always forward
requests
> from applications immediately.
> 
been
> used in other IETF documents.

I agree that having a 'queue mode' would be a nice feature, but I do not
believe that this is documented anyplace in this document.  Doing so would
require some additional text.  The current text says that messages are
always forwarded when they are received to a client.  If the client happens
to be asleep then it needs to go back and ask for the current value when it
wakes up.  

> In my review I have been wondering why we aren't re-using the concepts
from
> LWM2M here.
> 
> Regarding the "topics": I have read this a bit differently. For me, a node
has
> resources and it publishes those. Then, there are applications (Web
applications,
> smart phone apps) who sent requests for those resources. These resources
have
> to be identified somehow and in LWM2M there is a specific way of
addressing
> the standardized resources (and objects), as described in
> you want to be more generic here but I think it is important that there is
a
> standardized structure here and that we are not only talking in the style
of MQTT
> topics.

I do not follow how this came from my review.  Is this an independent item
or is it following from something that I asked in my review?

Jim

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 11 Aug 2016 18:14:32 +0200

Hi Jim,

I agree that there is more text needed on the support of so-called
sleepy nodes.

I may have over-interpreted your remarks about the topic.

Ciao
Hannes