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

[Jari Arkko <[e-mail]>]

Matthieu,

I have read your draft. I like it, and would very much like to see something like this as a part of the outputs from this working group. Your draft is kind of a well-designed REST version of what we did in admittedly rather ad hoc manner in draft-arkko-core-sleepy-sensors.

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?

A couple of comments on your open questions:

>     We need a way to identify a SEP registered in multiple proxies as a
>     single entity.  Otherwise clients may have a wrong view of the
>     available services during resource discovery.  The duplicate
>     resources are indeed seen as new devices.

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.

>
>     We need a simple mechanism to define allowed methods on mirrored
>     resources that is independant of the resource profile.  A second
>     Interface Description attribute with the CRUD letters might work.

I have no comment on this yet.

>     We may add a CoAP option that would permit a MP to indicate in a
>     response that a client has updated another writable resource in the
>     cache for the requesting SEP.  This would gives better response time
>     than polling.

Hmm. I think this needs further thought. Is there a way to ask "give me a list of my resources that have changed since yesterday"?

>
>     When a SEP registers with multiple MP and each MP reuses the same
>     SEP's name to register with the RD, the resource directory entry
>     might be overwritten.  We need to figure out what piece of
>     information is the handler for a resource directory entry in a RD
>     database.

We have some ideas on this front... stay tuned.

>
>       6.1. Extensions
>
>
>
>     Implicit registration could be useful for highly constrained SEP that
>     don't have enough energy to maintain soft state in a MP.  Like the
>     proposition in [I-D.arkko-core-sleepy-sensors  <http://tools.ietf.org/html/draft-vial-core-mirror-proxy-00#ref-I-D.arkko-core-sleepy-sensors>], we could use a
>     multicast address to infer a resource type.  Alternatively we could
>     allow explicit registration from a third-party endpoint.
>

For what it is worth, we took our implementation to the extreme limit. It is necessary to be able to create simple and power efficient devices, but there may be a reasonable limit that we do not have to cross. I think a constrained device can support a registration phase. The only problem that I have with registration phases is the issue that we experienced with coap-observe: we cannot assume that only one entity is interested in our results, we don't know when the addressing plan of the site changes,  and we don't want to stay on all the time in case someone re-registers (as a server) or poll continuously if there's a new register that we must register to (as a client). If those problems can be overcome for a RM function, then I'm fine with programming a discovery and registration mechanism into my devices.

Jari