Re: [core] Tr : New Version Notification for draft-vial-core-mirror-proxy-00.txt

[[e-mail]]

Jari,

Thanks for your interest in the draft. See my comments below.


>I also like it that your interface is pretty much identical to the RD 
interface, making this easier to implement. Question: if I want to 
register myself in a RM *and* an RD (which might potentially be in the 
same server), is there a way for me to send just one set of messages, or 
do I have to register twice?

For me a sleeping endpoint is not supposed to register with a RD. The 
mirror proxy can do it on its behalf if RD discovery is administratively 
configured in the network. When the RD and the MP are located on the same 
web server we can imagine internal optimizations to populate the RD 
database. Also by default the RD extracts the source address of the 
registration packet to get the address of the web server. A SEP is not a 
web server so it would have to explicitly specify the address of the MP in 
the registration request. It's just added complexity for a SEP and it's 
also less energy efficient.


>I would suggest that there could be a "origin" identity carried in the 
registration (e.g., dev:mac:....) and that origin identity can be 
communicated through the RD to anyone who sees the resources. This allows 
whoever is interested in the content to at least detect the duplicate 
resources as such.

The question is how to attach this identity to the web links returned 
during resource discovery.


>I think a constrained device can support a registration phase.

Depending on the energy harvesting technology, some devices might not be 
able to send periodic requests to maintain soft state or to start a 
complex registration procedure (link-format is quite verbose). A switch 
may collect energy from the movement of the rocker for example. In that 
case the SEP can only communicate when the switch is activated.

Matthieu