Subject: [core] Fwd: New Version Notification for draft-castellani-core-alive-00.txt

From: "Angelo P. Castellani" <[email-masked]>
Date: Thu, 29 Mar 2012 19:03:21 +0200

Dear WG,

we have written a novel, very simple proposal to deal with sleeping
server nodes.

The solution propose the use of a new message indicating the current
availability of a CoAP server, sent immediately after wake up.

If you mind having a look, you find it here:
http://tools.ietf.org/html/draft-castellani-core-alive

Best,
Angelo & Salvatore

---------- Forwarded message ----------
From:  <[email-masked]>
Date: Thu, Mar 29, 2012 at 18:59
Subject: New Version Notification for draft-castellani-core-alive-00.txt
To: [email-masked]
Cc: [email-masked]

A new version of I-D, draft-castellani-core-alive-00.txt has been
successfully submitted by Angelo P. Castellani and posted to the IETF
repository.

Filename:        draft-castellani-core-alive
Revision:        00
Title:           CoAP Alive Message
Creation date:   2012-03-29
WG ID:           Individual Submission
Number of pages: 6

Abstract:
  In the context of a Constrained RESTful Environment (CoRE), hosts
  could frequently be energy-constrained and be turned off the vast
  majority of time for energy-saving purposes.

  In the case of a CoAP server, while it is offline, it is neither
  available to serve requests.  Clients desiring to access its
  resources have no way to understand when they will find it up again.

  This specification provides a simple new message that gives to a CoAP
  server the ability to signal its current availability in the network.

The IETF Secretariat

---

From: Guido Moritz <[email-masked]>
Date: Thu, 29 Mar 2012 19:23:13 +0200

Angelo,

the first thoughts that come into my mind:

Couldn't this also be realized through using the existing observe, by modeling a dedicated observable resource as 'Alive' indicator. Clients can subscribe to the 'Alive' resource and may be get informed each time the node (1) wakes up and/or (2) the node is going into sleepy state.

Do you have a specific multicast address in mind to use, to not affect clients not interested in these notifications? 

If the Alive signal would be multicast, there is no reliability. Might it be worse having also a reliable version of this signal (i.e. CON)? Isn't this in turn similar to using observe then?

Best,
Guido

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] [mailto:[email-masked]] Im Auftrag von
> Angelo P. Castellani
> Gesendet: Donnerstag, 29. März 2012 19:03
> An: core
> Betreff: [core] Fwd: New Version Notification for draft-castellani-core-alive-
> 00.txt
> 
> Dear WG,
> 
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: "Angelo P. Castellani" <[email-masked]>
Date: Fri, 30 Mar 2012 08:54:58 +0200

Thanks Guido for your very interesting comments.

> Couldn't this also be realized through using the existing observe, by modeling a dedicated observable resource as 'Alive' indicator. Clients can subscribe to the 'Alive' resource and may be get inf…

It's a very good point yours actually, however the use case I am
targeting is different.

Probably you should have a look at this "Observer model" discussion:
http://tools.ietf.org/html/draft-arkko-core-sleepy-sensors-01#section-4.2.3

The alive message is targeting to address this initial establishment
problem pointed out by Jari.

> Do you have a specific multicast address in mind to use, to not affect clients not interested in these notifications?

Yes probably these notifications should be definitely sent to a
specific multicast address, or to a specific proxy anycast address.

> If the Alive signal would be multicast, there is no reliability. Might it be worse having also a reliable version of this signal (i.e. CON)? Isn't this in turn similar to using observe then?

As said before, the problem is that you have to be able to get this
sensor awake, in order to successfully observe that kind of resource.

There is also another problem, using Observe it costs you two messages
(and the "going to sleep" is really not useful at all), whereas the
"Alive" message uses a single one thanks to its special semantics.

Best,
Angelo