Subject: [core] draft-koster-core-coap-pubsub-04

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 23 Mar 2016 15:49:36 +0100

Hi authors, Hi all,

I was wondering about the status of <draft-koster-core-coap-pubsub-04>,
which describe functionality to allow "sleeping nodes" to outsource
state storage to some other node.

Currently draft-koster-core-coap-pubsub-04 is not a working group draft,
there is no milestone on the charter, and there has been no update of
the document for this IETF meeting.

Nevertheless, the CORE charter talks about this item:
"
CoAP will support various forms of "caching". For example, if a
temperature sensor is normally asleep but wakes up every five minutes
and sends the current temperature to a proxy that has subscribed, when
the proxy receives a request over HTTP for that temperature resource, it
can respond with the last seen value instead of trying to query the
Device which is currently asleep.
"

So, what is the roadmap for this item?

The milestones of the CORE WG are, btw, terrible out of date!

Ciao
Hannes

PS: What is the relationship to the draft-zotti-core-sleepy-nodes-04?

---

From: peter van der Stok <[email-masked]>
Date: Wed, 23 Mar 2016 16:48:27 +0100

> PS: What is the relationship to the draft-zotti-core-sleepy-nodes-04?
We wrote sleepy node draft to show that pubsub does not cover all sleepy 
node aspects.
Secondly, I think that pubsub should be developed independent of sleepy 
node requirements

Peter

---

From: Ari Keränen <[email-masked]>
Date: Tue, 29 Mar 2016 02:23:08 +0000

Hi Hannes,

> On 23 Mar 2016, at 11:49, Hannes Tschofenig <[email-masked]> wrote:
> 
> Hi authors, Hi all,
> 

The milestones and other WG formalities we can fix once the charter is approved (almost there, right?), but we are working on the draft. Unfortunately we didn't manage to update it for this meeting but we're planning to submit updated version soon. We believe the the draft basic functionality is pretty mature by now and if we do further extensions in separate drafts we should be able to progress this as WG item relatively fast.

Cheers,
Ari

---

From: Michael Koster <[email-masked]>
Date: Tue, 29 Mar 2016 07:02:04 -0700

Hi Peter,

Does it make sense to add support to pubsub for the requirements in the sleepy node draft? It doesn't seem to be that much different. Most of what's needed is incremental:

1. Discovery of registered topics on a broker by reading in /well-known/core 
2. Auto-registration of topics from the broker to an RD (already can be done using RD pull mode by sending the RD an empty post if the links are already in .well/known core)
3. Only allow the endpoint that registered links to publish - is this really needed? I didn't see an obvious use case or story presented in the sleepy node draft. if so, is it not a security issue as well as a protocol question? 
4. Describe separate roles in the architecture for registering, discovering, reading, configuring, and communicating. Good idea.
5. Queueing messages to sleepy nodes; inform a sleepy node about pending data by sending links in the response payload of a PUT/POST from the sleepy node - This may require some fundamental changes to the way some CoAP servers work, but it seems theoretically possible to return a payload on PUT and POST within CoAP specifications.

If you are not planning to take the sleepy node draft to standards track, pubsub could be a reference implementation. We already have 2 implementations of pubsub that I know of, and inquiries on other work in progress. We may also be able to evaluate these additions with the existing implementations.

Best regards,

Michael

> On Mar 23, 2016, at 8:48 AM, peter van der Stok <[email-masked]> wrote:
> 
> 
> We wrote sleepy node draft to show that pubsub does not cover all sleepy node aspects.
> Secondly, I think that pubsub should be developed independent of sleepy node requirements
> 
> Peter
> 
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: peter van der Stok <[email-masked]>
Date: Wed, 30 Mar 2016 13:55:42 +0200

Hi Michael,

Not sure what you mean.
Do you mean additions to the pubsub draft that are sleepy node focussed?
Or do you mean references from sleepy node draft to pubsub draft to show 
how pubsub could be used in the sleepy node context.
Teresa and I intended to do the latter once the pubsub draft became 
stable.

Peter

Michael Koster schreef op 2016-03-29 16:02:
> Hi Peter,
> 
> Does it make sense to add support to pubsub for the requirements in
> the sleepy node draft? It doesn't seem to be that much different. Most
> of what's needed is incremental:
> 
> 2. Auto-registration of topics from the broker to an RD (already can
> be done using RD pull mode by sending the RD an empty post if the
> links are already in .well/known core)
> 3. Only allow the endpoint that registered links to publish - is this
> really needed? I didn't see an obvious use case or story presented in
> the sleepy node draft. if so, is it not a security issue as well as a
> protocol question?
> 4. Describe separate roles in the architecture for registering,
> discovering, reading, configuring, and communicating. Good idea.
> 5. Queueing messages to sleepy nodes; inform a sleepy node about
> pending data by sending links in the response payload of a PUT/POST
> from the sleepy node - This may require some fundamental changes to
> the way some CoAP servers work, but it seems theoretically possible to
> return a payload on PUT and POST within CoAP specifications.
> 
> If you are not planning to take the sleepy node draft to standards
> track, pubsub could be a reference implementation. We already have 2
> implementations of pubsub that I know of, and inquiries on other work
> in progress. We may also be able to evaluate these additions with the
> existing implementations.
> 
> Best regards,
> 
> Michael
>

---

From: Michael Koster <[email-masked]>
Date: Wed, 30 Mar 2016 10:05:58 -0700

Some of the use cases in the sleepy node draft may make sense to include in the pubsub design. We could discuss each item listed and decide whether it makes sense to add support in pubsub. We could get feedback from implementers.

Also, store and forward would be a better way than queueing to describe delivery of a message to a sleepy node.

Michael

> On Mar 30, 2016, at 4:55 AM, peter van der Stok <[email-masked]> wrote:
> 
> Hi Michael,
> 
> Not sure what you mean.
> Or do you mean references from sleepy node draft to pubsub draft to show how pubsub could be used in the sleepy node context.
> Teresa and I intended to do the latter once the pubsub draft became stable.
> 
> Peter
> 
>