Re: [core] Should DNS usage of CoAP implementations favor SRV?

I agree that Kerry & company had several I-Ds that did do design work into the relationship between CoAP and DNS.  In fact, the Groupcomm I-D currently references some of these ideas for any appraoch beyond raw multicast IP manipulation:

http://tools.ietf.org/html/draft-ietf-core-groupcomm-03#page-5

So we need to decide as a WG if we want to support this approach or not.

Regards,

Akbar

From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Kerry Lynn
Sent: Friday, November 30, 2012 10:01 AM
To: Carsten Bormann; core
Subject: Re: [core] Should DNS usage of CoAP implementations favor SRV?

On Fri, Nov 30, 2012 at 5:02 AM, Carsten Bormann <cabo@tzi.org> wrote:

	CoAP is deliberately not tying itself to DNS in any major way.
	That is a good thing, as many CoAP deployments won't use DNS.
	But it also means we have never put any design work into the relationship between CoAP and DNS.

<kel> 

Peter, Anders, and I put out several CoRE drafts detailing how DNS could be
used to advantage in networks of CoAP nodes.  These have all expired but for
http://tools.ietf.org/html/draft-lynn-core-discovery-mapping-02.txt as it became
clear to us that there was not much support for these ideas within the group.

I am keeping the discovery-mapping I-D active because of its possible applicability
in mixed populations of SEP 2.0 devices where XML, HTTP, and DNS are the
baseline and it's expected that CoAP may find applicability.  In that environment,
we have extended DNS-SD/mDNS to discover REST function sets within a set
of servers and the discovery-mapping I-D describes how to achieve semantic
equivalence in the search down to that level of granularity using either DNS-SD/
mDNS or Core resource discovery.

I hope to find a home for the SEP 2.0 DNS-SD/mDNS extensions discussion in
the MDNSEXT WG when it is chartered.
</kel>

	One thing I'm no longer sure about after this week's plugtest is that, for those areas of application where DNS *is* appropriate, we should just blindly continue the way HTTP uses the DNS.
	That has pretty much been an accident, and there never has been a chance to retrofit something more sensible the way that MX was retrofit for mail.
	We may not have to invent anything new, though, because SRV has now been around a dozen of years.
	Is it time to put it to good use?  Cullen has suggested in the WGLC comments that we do that.

<kel> 

Cullen proposed an excellent scheme (literally) in
http://tools.ietf.org/html/draft-jennings-http-srv in which he suggested http+srv
could be used to advantage to bind a dynamic socket as well as an IP address
to an HTTP server location.

Peter, Anders, and I developed this concept for CoAP in
http://tools.ietf.org/html/draft-vanderstok-core-dna where, in particular, it will be
necessary to dynamically assign ports in the IPHC compressible range and then
discover this binding post-facto.

Before this, Angelo & Co. described how coap+srv could be used in HTTP-to-
CoAP mapping across a proxy where, one on side, the "host" production names
a host record and on the other an SRV RR (which binds host & port).
</kel>

	If yes, we should specify how SRV is used with CoAP.  _coap._udp?

<kel>
This is the conventional way that DNS-SD/mDNS names SRV/TXT records.  I
believe we'd also want to deploy PTR and TXT records in addition to SRV RRs
to allow for wildcard and resource discovery, respectively.  In practice, searching
for PTR RRs named _coap._udp is too general; you'd want to constrain the search
by using subtypes, e.g. light._sub._coap._udp.

The discovery-mapping draft is a good starting point but it needs work.  I hope
it can at least stimulate some discussion on this topic.

Regards, -K-
</kel>

	(Note that this doesn't need to be part of the base spec, as the base spec is not tied to DNS.)
	We most likely shouldn't go NAPTR, unlike, say, RFC 3263 does for SIP.
	What is the right way to use DTLS with SRV?

	(The related implementation issue that Klaus already brought up because it occurs with AAAA as well:
	What is the best way to "try to connect" (RFC 2782) to choose one out of multiple alternatives?
	"coap ping" was discovered as one way to aid this selection.)

	Grüße, Carsten

	_______________________________________________
	core mailing list
	core@ietf.org
	https://www.ietf.org/mailman/listinfo/core