Subject: [core] Some comments on draft-lynn-core-discovery-mapping-01

From: Thomas Fossati <[email-masked]>
Date: Mon, 14 Nov 2011 18:10:29 +0100

Hi Kerry and Zach,

I've read with much interest your draft on RD to DNS-SD mapping, and collected some comments and questions that I'd like to share.

* Section 1.4
- Perhaps being a little more informative on the dynamics of DNS-SD could be valuable for the casual reader, since going through Cheshire's draft can be a lengthy (though edifying) experience
- When you say "The SRV record contains the host name (AAAA record name)" should be "AAAA or A record" (i.e. CoAP over IPv4), right ?

* Section 2.1
- When you say "to the extent that the "ins" attribute may be chosen to match the DNS host name of a service", you mean that we may end up having duplicate hostname information in both {Instance} and the corresponding SRV record like this: "XXYYZZ._coap._udp SRV 0 0 5683 XXYYZZ" ?

* Section 2.2
- s/stings/strings/

* Section 2.3
- The {Domain} mapping is likely to be a policy issue WRT the DNS zone configuration.  It may as well be some default value that all imported services inherit -- i.e. the (sub)domain where the records are pushed -- or a function of some parameters (e.g. ct) of the resources involved in the RD->DNS-SD export.  I don't think that we need to specify a method, since every deployment may have to implement its own logics.

An overall comment that I'd like to do is that the RD->DNS-SD export mechanism is quite generic, and may be used to map to a different URI scheme than 'coap' (e.g. 'http').  In this regard, I suspect that the terminating "_udp" constraint on the {Service} labels is artificially limiting.  In fact, I'm playing with these same mapping mechanisms in the context of a HTTP-CoAP gateway and I find very useful to let my homenet (e.g. browsers) know about the things that are exported as HTTP services (_http._tcp) by the gateway.

Thank you very much for your effort.