Re: [core] resource-directory-4

["Dijk, Esko" <[e-mail]>]

Hello Floris, Zach,

> Shouldn't the default value for the con parameter in section 5.2 also be the 'default discovery URI' as in section 4? The draft states to use the source port as the context port, however this port will usually be a client port and will differ from the port the endpoint is listening on (e.g. port 60000 vs 5683).

Good point; maybe the reason that source port is written here is, that it’s the only information that is available (in the absence of information on the port the endpoint is listening on when ‘con’ is not included). That implies the client has to use as source port the same port that it is listening on.


> I don't agree that this a contradiction, the last line of 5.32 refers to the URI query parameters that are passed on (e.g. con, rt and lt) and not the CoAP Payload. So in my view this shouldn't be altered. Enforcing this on the payload as well, would seem to imply that the payload would be a patch of some sort (which seems to be out of the scope of the document).

To me it’s not clear from the text whether the PUT request to do an update overwrites the previous entries entirely (which would be most RESTful) or that “update” implies that only new and/or changed resources are included in the payload. (Then I would expect a POST rather than PUT)
Maybe an idea is allowing both PUT (to overwrite existing) or POST (to update existing) ?

Esko


From: [e-mail] [mailto:[e-mail]] On Behalf Of Floris Van den Abeele
Sent: Monday 28 January 2013 11:33
To: Zach Shelby
Cc: Core
Subject: Re: [core] resource-directory-4

Hi Zach&all,

I read and implemented the draft and interpreted the usage of the con parameter the same way as Zach did, i.e. to be used to update volatile IP addresses thus ensuring the reachability of the registered endpoint.

I also have a couple of comments/questions about draft-shelby-core-resource-directory-04:
* Shouldn't the default value for the con parameter in section 5.2 also be the 'default discovery URI' as in section 4? The draft states to use the source port as the context port, however this port will usually be a client port and will differ from the port the endpoint is listening on (e.g. port 60000 vs 5683).
* In draft-bormann-core-simple-server-discovery-00 a definition is given for the 'default discovery URI', I would suggest referencing it or adding it to the document in section 4. This definition does include the listening port instead of the source port.
* Peter wrote:

In the example of sec 5.3, the last line, </sensors/light>;ct=41;rt=”lightLux;if=”sensor” is identical to the 2nd line in the payload of the Registration example. This contradicts the last line of the intro of sec 5.32 Parameters (not Paremeters) that have not changed SHOULD NOT be included in an update. Better remove or change the last line in the Update example.
Good eye. Will change that.



I don't agree that this a contradiction, the last line of 5.32 refers to the URI query parameters that are passed on (e.g. con, rt and lt) and not the CoAP Payload. So in my view this shouldn't be altered. Enforcing this on the payload as well, would seem to imply that the payload would be a patch of some sort (which seems to be out of the scope of the document).

* Why reuse the rt accronym for end point type? This is confusing with the resource type that is defined in RFC 6690.

* There is small mistake in the last example of section 6. The example should be GET /rd-lookup/d instead of GET /rd-lookup/domain in the ASCII figure and the accompanying text beneath it.



Regards,

Floris
On ma 24 sep 2012 14:15:36 CEST, Zach Shelby wrote:


On Sep 24, 2012, at 11:12 AM, peter van der Stok wrote:



Hi Zach,

In relation to the point below, Some questions remain.






In sec 5.3 the con parameter is also mentioned to update the entry. In the case that the host:port changes completely, a new entry is required IMO. May be remove con from update?


The whole point of an update is that it would update a change in the
ip:port, as this can happen often. This way the endpoint name in the
RD is stable, and does not change even though the ip:port tuple
changes.


I understood that con could also be used with a scheme and a FQDN
e.g. con=coap://mynode.example.com
I hope that is correct.


Sure, assuming such an FQDN exists (often times that is not the case in M2M however).



Following your reasoning when using host:port, then
by reassigning changing IP addresses continuously to the RD end-points, the RD takes over DNS functionality?


Not at all. DNS just really isn't used in M2M today, as it is usually not practical or even possible to update DNS entries when nodes are often changing their IPv6 address due to changes in point of attachment or getting dynamic IP address assignment e.g. in Cellular networks.



Would it not be better to keep DNS functionality outside the RD, use FQDNs, and only use IP addresses when the environment does not support DNS.
In the latter case I do not see the IP addresses changing very frequently, because there is no IP provider either.


In theory an RD could keep track of the IP addresses of registered nodes using DNS, but that is really an implementation issue and not an interface specification one.

Zach




Greetings,

peter

________________________________
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.