Subject: [core] resource-directory-4

From: peter van der Stok <[email-masked]>
Date: Thu, 20 Sep 2012 09:44:55 +0200

Hi Zach,

Having read core-resource-directory-04, I do have a few questions:
In sec 5.2 the con parameter is mentioned which is very useful when the 
directory is filled from another device than the one that is registered. 
May be the relation of the con parameter to the “host relation” should 
be clarified.
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?
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.

Peter

-- 
Peter van der Stok
vanderstok consultancy
mailto: [email-masked]
www: www.vanderstok.org
tel NL: +31(0)492474673     F: +33(0)966015248

---

From: Zach Shelby <[email-masked]>
Date: Sun, 23 Sep 2012 21:48:57 +0300

Hi Peter,

> In sec 5.2 the con parameter is mentioned which is very useful when the directory is filled from another device than the one that is registered. May be the relation of the con parameter to the “host relation” should be clarified.

Yes, some text on that would be useful. And in general, the RFC5899 host relation should be described for the links registered to the RD. This usage is different enough than in RFC6690 that it needs to be defined again WRT what it is assumed to be when links are used this way (both during registration and lookup).

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

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

Thanks,
Zach

> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

-- 
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: peter van der Stok <[email-masked]>
Date: Mon, 24 Sep 2012 10:12:16 +0200

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.

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

Greetings,

peter

---

From: Zach Shelby <[email-masked]>
Date: Mon, 24 Sep 2012 15:15:36 +0300

> e.g. con=coap://mynode.example.com

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

> 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