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

From: Jari Arkko <[email-masked]>
Date: Fri, 09 Mar 2012 14:35:18 +0200

Matthieu, Zach,

I implemented an early prototype based on these drafts the other day. Or to be more precise, we have a couple of implementations, and wanted to provide some feedback on the drafts.

First, these are really important pieces of functionality for smart object networks, lightweight for small devices to implement, and architecturally well designed. It has been very easy to construct a small device that registers to a mirror proxy and makes just periodic updates.

But we're also hitting some number of problems, mostly in the area of the drafts being imprecise or lacking information. Or maybe we just have not found the right text or have simply misunderstood something. In any case, here are the issues that we run into:

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?

2. Same with draft-shelby, Section 4.2.

3. Section 5.10.8 in coap base draft in imprecise and inconsistent in its definition of what path should be included in the option. It says "absolute path URI" but also that "the Location-Path attribute is similar to Uri-Path option" and that it "may occur multiple times". Is Location-Path a segment or the full path? Uri-Path option in turn is defined elsewhere as  "one segment of the absolute path to the resource". I think it would make far more sense for Location-Path to be a segment, because a device needs to copy information from Location-Path to Uri-Path on subsequent communications.

    "The Location-Path and Location-Query Options indicates the location
    of a resource as an absolute path URI.  The Location-Path Option is
    similar to the Uri-Path Option, and the Location-Query Option similar
    to the Uri-Query Option.

    The two options MAY be included in a response to indicate the
    location of a new resource created with POST.

    If a response with a Location-Path and/or Location-Query Option
    passes through a cache and the implied URI identifies one or more
    currently stored responses, those entries SHOULD be marked as not
    fresh.

    Both options are "elective" and MAY occur one or more times."

4. If our suggestion about the correct definition of Location-Path above is adopted, examples from Section 5.2 in draft-vial need fixing. Currently they include the absolute URI, including the leading slash.

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?

    "If a resource has been created on the server, a 2.01 (Created)
    response that includes the URI of the new resource in a sequence of
    one or more Location-Path Options and/or a Location-Query Option
    SHOULD be returned.  If the POST succeeds but does not result in a
    new resource being created on the server, a 2.04 (Changed) response
    SHOULD be returned.  If the POST succeeds and results in the target
    resource being deleted, a 2.02 (Deleted) response SHOULD be returned."

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.

7. Section 5.8.2 and 5.9.1.1 in coap base draft seem to disagree (?) about whether Location-Path should be returned. Compare the above quote to the below one:

    "If the response includes one or more Location-Path Options and/or a
    Location-Query Option, the values of these options specify the
    location at which the resource was created.  Otherwise, the resource
    was created at the request URI."

8. Sections 5.8.2 and 5.9.1.1 in base and Section 4.2 in draft-shelby have a different requirement (SHOULD vs. MUST) for when to include a Location-Path attribute. Is this intentional for this specific use of COAP, or an inconsistency?

       Success:  2.01 "Created".  The Location header MUST be included with
       the new resource entry for the end-point.  This Location SHOULD be
       an stable identifier generated by the RD as it is used for all
       subsequent operations on this registration (update, delete).

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?

    The discovery procedure is identical except that the resource type is
    replaced with "core-mp".

    I think it goes to the rt parameter when doing a .well-known query, but does this mean that I *have* to do discovery every time, even if I already have been configured with the address of an RD or MP? In many configurations the address needs to be configured because there is no easy way to do discovery beyond the local link.

10. Section 3.1 in draft-shelby needs some work to explain what discovery approaches can work in mobile networks (or any other networks that are not local LANs and may include router hops or even NATs).

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
     - registration
     - update
     - mirror put
     - get uri
     - get query parameters
     ...

     Please specify and provide some overall explanation of what should go where, and why.

     For instance, why isn't host:port sufficient to distinguish different instances as opposed to host + instance? When should the location-path be used, and when the host + instance? Are some values secret and to be used only by the node that registered, while others are to be used by anyone? And so on.

12. The lookup interface only allows using ep, link-format parameters, and domain. Why? Can I lookup based on the URI as provided by Location-Path? Can I look up based on host name? Can I look up based on host IP address if the host gave its address as a host name? Can I look up the different instances if I just know the host name, if so, how?

13. Section 4.2 of draft-shelby it says:

    "In the absense of a Host parameter, the RD will generate a unique one on behalf of the end-point."

    This seems odd. The purpose of the of the RD is to enable others to reach the devices, so what kind of "unique host parameter" should be generated? The source address + port from the query? A random string? A host name added to dyndns, or something else? Please specify.
Jari

---

From: [email-masked]
Date: Fri, 9 Mar 2012 15:41:20 +0100

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

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 9 Mar 2012 17:13:23 +0100

On Mar 9, 2012, at 13:35, Jari Arkko wrote:

> Is Location-Path a segment or the full path? 

A single Location-Path Option is a (percent-decoded) segment of the URI offered as the Location.
The name of the option is a bit historical (but Location-Path-Segment or Uri-Path-Segment are a bit long).

When talking about the value of the sequence of options, it is a bit more intuitive to instead talk about the implied URI.  Notated in a HTTP header style:

Location: /foo/bar

is a short form of »two Location-Path options "foo" and "bar"«.

Yes, we need to get consistent here -- either use that notation and explain it or use the actual option values.  I still like to talk about /.well-known/core etc. instead of saying [{"Location-Path": ".well-known"}, {"Location-Path": "core"}] (or, worse, "\x6B.well-known\x04core").

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 9 Mar 2012 17:17:03 +0100

>   was created at the request URI."

This seems to be hard to get right :-)

See http://trac.tools.ietf.org/wg/httpbis/trac/ticket/331 -- we should aim to be culturally compatible.

Grüße, Carsten

---

From: Jari Arkko <[email-masked]>
Date: Fri, 09 Mar 2012 18:59:54 +0200

Carsten,

> Yes, we need to get consistent here -- either use that notation and explain it or use the actual option values.  I still like to talk about /.well-known/core etc. instead of saying [{"Location-Path…

You can certainly still talk about paths such as /.well-known/core in the text, but if you actually write an example that has lines like Location: /.well-known/core that is always going to be confusing, no matter what explanations you might add to the text. The point of an example is to show the real messages and attributes, and shorthand notations there is misleading. IMO, of course.

Jari

---

From: Zach Shelby <[email-masked]>
Date: Sat, 10 Mar 2012 11:10:49 +0200

> You can certainly still talk about paths such as /.well-known/core in the text, but if you actually write an example that has lines like Location: /.well-known/core that is always going to be confu…

The RD draft is agnostic to whether CoAP or HTTP is used, thus the examples are as generic as possible. I think in CoRE it might be good to write up a draft that recommends a notation for specifying or giving examples of generic REST exchanges in drafts (other than the use of WADL). 

Zach

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://www.sensinode.com
http://zachshelby.org  - My blog "On the Internet of Things"
http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297

---

From: Jari Arkko <[email-masked]>
Date: Tue, 27 Mar 2012 08:43:39 +0200

Incidentally, as a part of our work on testing public key crypto on small devices, we also implemented an early prototype to give end-to-end security for mirror proxying. We think the approach has some appeal, given that validity can be checked at any time, through any number of proxies, can use zero-config or SSH like models, etc. Obviously this is very early work and we don't have all the pieces that we'd need to make this work fully. But nevertheless, we're putting it out for your consideration:

http://tools.ietf.org/html/draft-aks-crypto-sensors-02

(We also have some slides from the smart object security workshop about this, see http://www.arkko.com/publications/draft-aks-preso.pdf)

Jari