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

[Jari Arkko <[e-mail]>]

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