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

> 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"?

Agree! This could be the way to go if we do not want to define another CoAP Option. It could be "give me a list of my resources that have changed since last time I checked". That seems far more scalable than a SEP polling all its resources for changes. If there's no change the SEP can quickly go to sleep again.

One way for the SEP to query the MP for this could be like this (just an ad-hoc query syntax here...):
        GET /mp/0?change

MP responds with:
        2.05 Content
        Content-Type: application/link-format
        </mp/0/dev/n>,</mp/0/some/writable/path>

where the default rel="hosts" relation is used, though it might be another (rel="updated" ??)
The SEP has to parse these link-format descriptions, but in general link-format parsing was already part of the specified SEP behavior in this draft.

Esko

-----Original Message-----
From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Jari Arkko
Sent: Friday 2 March 2012 15:17
To: matthieu.vial@non.schneider-electric.com
Cc: core WG
Subject: Re: [core] Tr : New Version Notification for draft-vial-core-mirror-proxy-00.txt

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

_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core

________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.