[core] RE feedback on resource-directory and mirror-proxy (and base) drafts

[[e-mail]]

Hi Jari,

Few comments inline.

> 1. Section 5.2 in draft-vial uses "Location: /mp/0" when I think you 
mean Location-Path from the coap base draft. Or am I missing something?

I suppose the reason is that earlier version of CoAP didn't split the path 
and the old notation is easier to read in examples. But if it just creates 
confusion I can change this to make it consistent with the last CoAP spec.

>5. Section 5.8.2 in coap base draft says that Location-Path is not 
returned for 2.04 results. This may be problematic. If I am a sensor who 
has previously registered, will register again after some reboot or the 
like but has forgotten state from previous times, it does not know what 
the location might have been. Is there a downside to including 
Location-Path in every 2xx result for POST?

My opinion is to process a registration request as if it were always a new 
creation. So a POST response always returns Location-Path options. You 
need to implement registration as an idempotent request for that. A new 
registration just overwrites previous state. As I understand the RD draft 
the h query parameter is the primary identifier for a RD entry. Since this 
parameter is optional it could be tricky to implement an idempotent POST 
when h is omitted (perhaps use source address as a fallback primary 
identifier). Personally I'd prefer using a unique identifier of the device 
(EUI64) as a primary identifier for the RD/MP entry. Previous versions of 
the RD draft had an id parameter but it was also optional.

>6. More generally, how does mirroring work when clients reboot, forget 
their state, move from one address to another, etc.? A paragraph or two 
explaining this would be useful.

What is a Client in your sentence? sleeping endpoint (SEP) in MP draft, 
endpoint (EP) in RD draft or a client in MP draft. I assume SEP hereafter.
If the SEP can store its MP entry location in flash it should check that 
its MP entry is up-to-date after reboot using ETAG. When the MP entry is 
not fresh or deleted the SEP should update or register again. If the SEP 
can't store state it should register after reboot. If the SEP registers 
with a different MP there may be a cache with stall content in another MP 
until the MP entry expires.
If a SEP changes its address I don't think there is a big impact on 
mirroring because it's the MP address which is advertised.
If an EP changes its address then the consumers of the services hosted on 
this EP need to restart discovery. Of course the MP is also an EP.

>9. How do I know whether a particular POST message (for instance) is 
directed to an RD or MP? Where does the "resource type" from the below 
statement (s4.1, draft-vial) go? How do clients know they have to use 
"/rd" path when talking to the RD?

resource type is the rt attribute in link format.
A web server with RD and MP services advertises resources like that:
</rd>;rt="core-rd",
</mp>;rt="core-mp"

The result of the resource lookup gives you the root path of the 
corresponding service.
The address of this server can be configured out-of-band but the (S)EP 
still needs to discover the root path of the service or at least to check 
that the configured URI has the good resource type.


> 11. We have trouble understanding the usage of various identifiers 
(host, instance, location, ep) and the logic behind selecting this 
particular design. Which identifier can be used in

Me too :)
- Instance is not clear to me.
- For MP, the Location path is the root path under which the cached 
resources are created *and* the resource where is located the MP entry. 
Now there may be a conflict between the path used to refresh the MP entry 
and the path corresponding to the root resource of the SEP. The difference 
between /mp/0 and /mp/0/ is effectively very subtle. I suppose the latter 
should end with an empty Uri-Path option.
- For RD, the arbitrary index included in the path is usually the primary 
key of a database table used to store data about an EP. The idea is to be 
able to update various metadata associated to an EP from a third-party 
client (typically a commissioning tool). So there is a need for a stable 
identifier. But RD lacks an interface to enumerate or query the registered 
EPs, so it's not clear how a third-party can access those identifiers. 
This new interface was discussed briefly on the mailing list.

Matthieu