Subject: Re: [core] resource-directory-4

From: Floris Van den Abeele <[email-masked]>
Date: Mon, 28 Jan 2013 11:33:12 +0100

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

---

From: "Dijk, Esko" <[email-masked]>
Date: Mon, 28 Jan 2013 13:03:42 +0000

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…

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: [email-masked] [mailto:[email-masked]] 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:

* 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

Hi Zach,

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?

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.