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

[Michael Koster <[e-mail]>]

Hi Jim,

replies inline

> On Aug 4, 2016, at 12:35 PM, Jim Schaad <[e-mail]> wrote:
> 
> 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.

Each client should be sent all notifications that its subscriptions require, even if they are published faster than they notified. 

What is actually buffered needs to include payloads and content formats, not necessarily entire messages.

> 
> 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.
> 
Yes, good point. publication on a topic needs to reset the lifetime counters of all topics in its path.
 
> 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.
> 
The access control would use the same mechanisms as resource access control, so it would be ACLs most likely. We wil add this to the security considerations!

> 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.

Yes, please see the email response to Peter van der Stok I sent out earlier.
> 
> 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".
> 
Thanks, yes, Sorry for the attack on your sanity ;-)

> Section 7 - Should there be advice on how to distinguish between a new
> publish and a re-publish because a response was not received?
> 
Hmm yes based on the CoAP MID I suppose. Good catch.

> 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.)
> 
yes a pubsub broker is a DTLS endpoint.

> 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?
> 
It's meant to say that the CoAP header (e.g. content-type option) is needed to correctly notify subscribers.

> 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.
> 
Yes, we removed the guidance to use/not use confirmable because it is a transport layer function.

I see we may want to make it explicit that notify behavior is the same as resource state notification. 

If a broker uses CON to notify, then it must follow the state machine behavior for CON.

It is not required to use CON to notify if publish uses CON. this is where pubsub differes from a message store-and-forward.

Subscription uses CoAP Observe, so whatever mechanism is implemented to remove observers that no longer have a security relationship applies here.

We wil be updating the draft again this week. Please let us know any further questions and suggestions.

Thanks!

Best regards,

MIchael

> 
>