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

[Jari Arkko <[e-mail]>]

Matthieu:

> 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.

OK. That makes sense. So when the MP is register itself with an RD, it does so to register the mirrored resources, not the original client.


>   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.

Yes. In any case, what is important for me is that I don't have to use multiple message rounds just to do both directory and mirroring; I just do one thing and the mirror takes care of directories for me.


>
>
>> 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.

As a separate attribute? (But I haven't looked at the details...)

>
>
>> 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.

Yes. I think registration phase is probably OK, periodic soft state maintenance.... might not be. But it depends on the timings, too. And those timings have real-world trade-offs on how well you can not just save power but also deal with changes and problems. The issue is that once something changes, you do not want wait for a month for all of your devices to  re-register, if the soft state maintenance timers were set to a month to save power.

Jari

>
> Matthieu
>