Re: [core] sleepy nodes

[peter van der Stok <[e-mail]>]

Hi Gengyu,

Zach made a proposal what the proxy could look like.
For me the proxy probably is not "too much" resource constrained.
The Resource directory or the router may make an excellent host.
But I can also see manufacturers selling them in any form they like.

Greetings,

Peter


weigengyu schreef op 2013-10-16 04:43:
> Hi, perter,
> 
> "Taking the advice of Zach, that you only want to define a proxy leaves
> also many possibilities open, like: ...... "
> 
> Could you give further explanations about the proxy.
> Is the proxy a resource constrained node?
> 
> Regards,
> 
> Gengyu
> 
> -----原始邮件----- From: peter van der Stok
> Sent: Tuesday, October 15, 2013 7:49 PM
> To: Core ; akbar rahman
> Subject: [core] sleepy nodes
> 
> 
> Dear all,
> 
> 
> reading the draft on the need for sleepy nodes by Akbar, I become more
> convinced that the subject is not right for IETF.
> Already defining a sleepy node is fraught with application oriented
> aspects.
> Taking the advice of Zach, that you only want to define a proxy leaves
> also many possibilities open, like:
> 
> Does the sleepy node communicate only with the proxy?
> Can the sleepy node send to other nodes than the proxy via multicast or
> unicast?
> Does the sleepy node need maintenance?
> Is the sleepy node initialized at the factory and it never listens to
> any messages afterwards?
> Or is there an initialization capability, eventually supported by a
> battery recharge.
> 
> 
> I can go on and on like this, (for example on timing constraints) and
> none of the questions will get satisfactory unanimous answers.
> Therefore, I remain with my conclusion that sleepy nodes are 
> interesting
> but too much conditioned by application constraints to define a proxy
> approach that is generally applicable.
> 
> If anything needs to be done I still think that the "mirror server"
> draft is the best choice because I recognize the boundary conditions.
> But the latter is a very application biased opinion.
> 
> Peter