Subject: [core] WGLC draft-ietf-core-observe-11: support for pre-configured observers ?

From: "Dijk, Esko" <[email-masked]>
Date: Mon, 21 Oct 2013 15:55:55 +0000

Dear all,

Just a thought. I was wondering if observe would also support pre-configured observers. With that I mean a server is preconfigured to send to send change notifications for a specific resource to a specific preset CoAP endpoint (client). One could also call it a persistent observe relationship; if the CoAP server reboots it continues sending the observe notifications.

This could be of interest for sleepy device / intermittent connectivity use cases, where it was previously noted that contacting the sleepy endpoint to do the first part (registration) would likely fail. Was it ever considered? Are there immediate reasons why this wouldn't work? (e.g. inability of client to re-register once it has been un-registered from notifications)

Esko

________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

---

From: "Kovatsch Matthias" <[email-masked]>
Date: Mon, 21 Oct 2013 16:12:48 +0000

Dear Esko

Do we need special support for that?
If the client implementation is prepared for this, it will just work.
If it is not, it will reject the notifications or the garbage collection will take care.

May a short separate informational document is useful to tell people about this possibility and maybe some best practices (although I cannot think about many different ways to do this..).
I while ago I thought about this to get rid of the client role in servers to register with an RD.

Ciao
Matthias

From: [email-masked] [mailto:[email-masked]] On Behalf Of Dijk, Esko
Sent: Montag, 21. Oktober 2013 17:56
To: core ([email-masked])
Subject: [core] WGLC draft-ietf-core-observe-11: support for pre-configured observers ?

Dear all,

Esko

---

From: Klaus Hartke <[email-masked]>
Date: Mon, 21 Oct 2013 19:48:48 +0300

Hi Esko,

there are indeed multiple cases where the goal is in principle
synchronize the state at one or more nodes to a "master state" (this
is what draft-ietf-core-observe provides) but the registration
mechanism defined in draft-ietf-core-observe doesn't really work.

Examples that have come up in discussions and drafts are:

- Synchronizing the state at each member of a multicast group to a
master state. (-groupcomm)

- Synchronizing the state at some mirror server to the master state at
a sleepy sensor node. (-mirror-server)

- Synchronizing the state at a single server in the cloud to the
master state at a constrained node. (-no-response-option)

- IIRC, Zach had some use-case where he wanted to send notifications
to a different node than the one registering.

So, yes, it makes a lot of sense to consider alternative registration
mechanisms, such as a static list of pre-configured observers as you
propose. This is on my list of next steps after
draft-ietf-core-observe is finished.

Technically, it should be trivially possible to send unsolicited
notifications to a client (or intermediary in the role of the client)
if the client can infer the all necessary context from the token.
There are some security concerns that need to solved first. (For
example, registering a multicast group as an observer was proposed at
IETF78 in 2010 but was shot down due to amplification issues.)

Best regards,
Klaus

On 21 October 2013 18:55, Dijk, Esko <[email-masked]> wrote:
> Dear all,
>
>
>
> Just a thought. I was wondering if observe would also support pre-configured
> observers. With that I mean a server is preconfigured to send to send change
> notifications for a specific resource to a specific preset CoAP endpoint
> (client). One could also call it a persistent observe relationship; if the
> CoAP server reboots it continues sending the observe notifications.
>
>
>
> This could be of interest for sleepy device / intermittent connectivity use
> cases, where it was previously noted that contacting the sleepy endpoint to
> do the first part (registration) would likely fail. Was it ever considered?
> Are there immediate reasons why this wouldn’t work? (e.g. inability of
> client to re-register once it has been un-registered from notifications)
>
>
>
> Esko
>
>
>
>
> The information contained in this message may be confidential and legally
> protected under applicable law. The message is intended solely for the
> addressee(s). If you are not the intended recipient, you are hereby notified
> that any use, forwarding, dissemination, or reproduction of this message is
> strictly prohibited and may be unlawful. If you are not the intended
> recipient, please contact the sender by return e-mail and destroy all copies
> of the original message.
>
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core
>

---

From: "Peter A. Bigot" <[email-masked]>
Date: Mon, 21 Oct 2013 12:02:34 -0500

> Do we need special support for that?

Only if a request is expected to be part of a REST transaction.

If not, this just works, and a CoAP transaction consists of zero or one 
requests to which there are zero or more (cf. observe) responses from 
one or more (cf. groupcomm) servers.  Each of these requests or 
responses is in turn comprised of one or more (cf. block) messages which 
themselves are requests and responses, where the responses are 
aggregated in some way to produce the overall response(s).

This would be a useful extension.

Peter

---

From: Thomas Fossati <[email-masked]>
Date: Mon, 21 Oct 2013 19:17:22 +0100

> to a different node than the one registering.

Then what Esko proposes would be just a Server self-request with a
different observer than the registering node.