Re: [core] resource-directory-4

[Zach Shelby <[e-mail]>]

Hi Floris,

Thanks for the RD draft feedback and implementation experience. See my comments in-line:

On Jan 28, 2013, at 11:33 AM, Floris Van den Abeele <[e-mail]> wrote:

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

Well, those are different things. The default discovery URI defines the default CoAP destination port you can expect to find an RD interface at. 

The location of the Endpoint that you are registering which will be exposed to a client doing an RD lookup in order to contact your Endpoint is of course different than the location of the RD itself. So it doesn't make sense to somehow assume that every Endpoint is at port 5683, since many entities can host multiple Endpoints, for example a gateway type of device. 

The idea behind the RD registration is that the Endpoint should register from the same socket that it is using to listen for incoming requests to that Endpoint. Thus the source port would be correct. So far we have not seen any implementation reasons why that is not possible. This also saves overhead when registering, not requiring the con parameter to be included. We have been using this model widely and it has worked great. 

Now the con parameter is actually meant to allow a 3rd party to register on behalf of an Endpoint. For example you might have a Proxy RD that accepts local registrations and then registers on behalf of those Endpoints to another RD.   

> * 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).

Yes, you are actually correct. That section is referring to the query parameters, and not the payload. 

I actually would like to simplify the Update further and remove the payload completely. Just do a new Registration if the links change. 

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

The reason for this is that the RD is modelled as a resource hierarchy itself. Thus the Endpoint entry is just a resource in the RD, and thus the Resource Type of that entry happens to describe the type of Endpoint. You can see that when you look at the RD lookup structures, as the Endpoints are described as RFC 6690 links.

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

Fixed.

Regards,
Zach

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

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://www.sensinode.com @SensinodeIoT
Mobile: [phone]
Twitter: @zach_shelby
LinkedIn: http://fi.linkedin.com/in/zachshelby
6LoWPAN Book: http://6lowpan.net