Subject: [core] Continuing the Resource Directory and DNS-SD discussion

From: Michael Koster <[email-masked]>
Date: Fri, 7 Apr 2017 08:03:27 -0700

Hi,

The last discussion as I recall from the CoRE meeting was around 3 points:

1. Using DNS-SD to find a resource directory

2. Providing "ins" and "exp" link attributes 

3. Specifying DNS-SD mapping to links in the RD document

We have already decided for points 1 and 2 within the scope of the RD document. We are discussing whether the DNS-SD mapping should be published in the RD document.

At IETF 98 we had two discussions..

First, should DNS-SD mapping be included in the RD draft?

This question can be informed by the requirements for the mapping itself and the expected use case of the mapping.

Based on the discussion below, there is a case to be made for publishing the mapping or RD links to DNS-SD records as a separate document.

- DNS-SD is not required to use RD. It would not be helpful to couple RD and DNS-SD unnecessarily by creating intra-document dependencies.
- A good use scenario and introductory explanation is needed, describing the relationship of RD to DNS-SD, which may be better served in its own document.
- Additional constraints on the use of RD are needed to facilitate the mapping, such as limiting the length of identifiers, requiring the presense of the "rt" attribute, requiring the use of "ins" and "exp". What is mandatory in RD?
- The rd-dns-sd draft can refer to RD normatively and publish in the same time frame, since the 2 documents will both be working group adopted and have good support. The RD document will not need to refer to the RD-DNS-SD document normatively.

There is a github repository with this work in progress and issues tracking:
RD document: https://github.com/core-wg/resource-directory <https://github.com/core-wg/resource-directory>
RD to DNS-SD mapping document: https://github.com/core-wg/rd-dns-sd <https://github.com/core-wg/rd-dns-sd>

The second question was to clarify the mapping itself, and its use case. We had several enlightening discussions, which I will try to summarize here.

What is DNS-SD mapping and how does it work? What are the use cases and what assumptions do they drive?

The big bit seems to be service discovery vs. resource discovery

The use case for DNS-SD is service discovery across broad network scope, including mesh and bridged/routed networks. 

The use case for RD is fine grain resource discovery using hyperlinks, as part of a REST client-server state machine. Clearly these are mostly complementary use cases, and it is easy to build service discovery on top of REST. Resource Directories are themselves REST servers and can respond to multicast discovery queries, but have no well defined discovery proxy for routed and bridged networks. Once the RD address is known, it can participate in REST interactions through unicast transactions. 

The use case for RD to DNS-SD mapping is in making DNS-SD services discoverable as RD registered endpoints and links, and to make RD registered endpoints and links discoverable as DNS-SD services.

Based on this, a system could bootstrap resource discovery by advertizing the resource directory location(s) usind DNS-SD and the link mapping to RD services; e.g. links with "rt=core.rd;rt=core.rd-lookup-res;core.rd-lookup-ep" etc. would be registered in an RD and exported to DNS-SD. Other RD services in the network would expose links to the RD services that were discovered over DNS-SD. In this way, all of the RD services that are only reachable using unicast could be discovered in "local" RD services. DNS-SD would be used to keep all of the RD service locations discoverable through RD on local network scope.

A number of assumptions and requirements for the mapping:

Links registered in RD for export to DNS-SD use the "rt" link attribute for translation to DNS service type name and transmitted as a SRV record.

Link context, consisting of scheme+authority+port, will be translated to a DNS service location and transmitted as a PTR record.

The remaining information in the link, or perhaps the entire link, will be transmitted in DNS-SD as a TXT record.

Based on these discussion, I am recommending that the DNS-SD mapping to RD links be taken up in a separate document, to normatively refer to the RD document, and be published in the same time frame in order to enable systems to use both RD and DNS-SD together.

---

From: peter van der Stok <[email-masked]>
Date: Mon, 10 Apr 2017 11:53:12 +0200

Thanks Michael,

Given the minutes of DNS RD Friday telco, I do have some concrete 
questions (and opinions).
Your discussion below is an excellent fulcrum.

Michael Koster schreef op 2017-04-07 17:03:
> We have already decided for points 1 and 2 within the scope of the RD
> document. We are discussing whether the DNS-SD mapping should be
> published in the RD document.

Are adding points 1 and 2 to RD confirmed? What is the outcome on point 
3?

> - DNS-SD is not required to use RD. It would not be helpful to couple
> RD and DNS-SD unnecessarily by creating intra-document dependencies.

I don't understand; You will need a reference from RD to DNS and DNS-SD 
anyway
A link from DNS-SD to RD may be profitable, if Stuart sees a place for 
RD in the context of its future Thread developments.

> - A good use scenario and introductory explanation is needed,
> describing the relationship of RD to DNS-SD, which may be better
> served in its own document.

That also applies to RD in its present state; why does RD exist, given 
we have DNS.

> - Additional constraints on the use of RD are needed to facilitate the
> mapping, such as limiting the length of identifiers, requiring the
> presense of the "rt" attribute, requiring the use of "ins" and "exp".
> What is mandatory in RD?

If ins and exp are added to RD, then these constraints belong there IMO.

> - The rd-dns-sd draft can refer to RD normatively and publish in the
> same time frame, since the 2 documents will both be working group
> adopted and have good support. The RD document will not need to refer
> to the RD-DNS-SD document normatively.

I agree, what did the friday discussion conclude?

> The big bit seems to be service discovery vs. resource discovery

I prefer fine grained versus coarse grained.

> 
> The use case for DNS-SD is service discovery across broad network
> scope, including mesh and bridged/routed networks.
> 
> The use case for RD is fine grain resource discovery using hyperlinks,
> as part of a REST client-server state machine. Clearly these are
> mostly complementary use cases, and it is easy to build service
> discovery on top of REST. Resource Directories are themselves REST
> servers and can respond to multicast discovery queries, but have no
> well defined discovery proxy for routed and bridged networks. Once the
> RD address is known, it can participate in REST interactions through
> unicast transactions.

I don't understand the paragraph above. That's all a bit too fast for 
me.
What I took back with me from this discussion:
We need to explain that RD transports less data than DNSSD for the same 
information content,
and we need to explain that filtering in RD takes little code space and 
processor time.

> 
> The use case for RD to DNS-SD mapping is in making DNS-SD services
> discoverable as RD registered endpoints and links, and to make RD
> registered endpoints and links discoverable as DNS-SD services.

I understand the second but not the first.

> 
> Based on this, a system could bootstrap resource discovery by
> advertizing the resource directory location(s) usind DNS-SD and the
> link mapping to RD services; e.g. links with
> "rt=core.rd;rt=core.rd-lookup-res;core.rd-lookup-ep" etc. would be
> registered in an RD and exported to DNS-SD.

So far, so good.

  Other RD services in the
> network would expose links to the RD services that were discovered
> over DNS-SD. In this way, all of the RD services that are only
> reachable using unicast could be discovered in "local" RD services.
> DNS-SD would be used to keep all of the RD service locations
> discoverable through RD on local network scope.

And here I am lost.

> Links registered in RD for export to DNS-SD use the "rt" link
> attribute for translation to DNS service type name and transmitted as
> a SRV record.

Is that so?

> 
> Link context, consisting of scheme+authority+port, will be translated
> to a DNS service location and transmitted as a PTR record.

Sounds correct and doable in an automatic fashion
> 
> The remaining information in the link, or perhaps the entire link,
> will be transmitted in DNS-SD as a TXT record.

needs some discussion, but doable.
> 
> Based on these discussion, I am recommending that the DNS-SD mapping
> to RD links be taken up in a separate document, to normatively refer
> to the RD document, and be published in the same time frame in order
> to enable systems to use both RD and DNS-SD together.

What did you conclude on Friday?

I am glad this discussion gets the attention it deserves. I hope there 
is enough energy to bring it to a conclusion (RFC)

Cheerio,

Peter

---

From: "weigengyu" <[email-masked]>
Date: Wed, 12 Apr 2017 11:30:42 +0800

Hi Michael, 

We are also intersted in this topic.  

> 1. Using DNS-SD to find a resource directory
If to find/resolve a RD server in the internet, DNS is also required when DNS-SD is not avalable.

> 2. Providing "ins" and "exp" link attributes 
Yes.

> 3. Specifying DNS-SD mapping to links in the RD document
It seems clear that to resolve a RD server, CoAP, HTTP, DNS-SD are available. 
If to resolve a resourece registered in a RD server, CoAP is available already.  Dose it try to have DNS-SD available too? 

> This question can be informed by the requirements for the mapping itself and the expected use case of the mapping.

First of all, what the objective is by adoptng DNS-SD? 
To resovle a CoAP node/resources, or to resolve a RD server?  

> - DNS-SD is not required to use RD. It would not be helpful to couple RD and DNS-SD unnecessarily by creating intra-document dependencies.
Yes. But DNS or DNS-SD have the data of the “registered” RD server(s), and knows which RD to have.  

> - A good use scenario and introductory explanation is needed, describing the relationship of RD to DNS-SD, which may be better served in its own document.
Yes

> - Additional constraints on the use of RD are needed to facilitate the mapping, such as limiting the length of identifiers, requiring the presense of the "rt" attribute, 
>    requiring the use of "ins" and "exp". What is mandatory in RD?
Yes. Considering the current length limites of DNS/DNS-RD, it may be realistic to use DNS or DNS-SD to resolve a RD server instead of CoAP server or resources.  

> - The rd-dns-sd draft can refer to RD normatively and publish in the same time frame, since the 2 documents will both be working group adopted and have good support. 
>    The RD document will not need to refer to the RD-DNS-SD document normatively.
If DNS-SD is tried to resolve a CoAP server or resources, a separate document is better. 

> The use case for RD is fine grain resource discovery using hyperlinks, as part of a REST client-server state machine. Clearly these are mostly complementary use cases, 
> and it is easy to build service discovery on top of REST. Resource Directories are themselves REST servers and can respond to multicast discovery queries, 
> but have no well defined discovery proxy for routed and bridged networks. Once the RD address is known, it can participate in REST interactions through unicast transactions. 

> The use case for RD to DNS-SD mapping is in making DNS-SD services discoverable as RD registered endpoints and links, and to make RD registered endpoints and links discoverable 
I do not agree that  “making DNS-SD services discoverable as RD registered endpoints and links, and to make RD registered endpoints and links discoverable as DNS-SD services.”

My suggestion is just to make a RD server discoverable as DNS-SD service. 

>Based on this, a system could bootstrap resource discovery by advertizing the resource directory location(s) usind DNS-SD and the link mapping to RD services; e.g. links
> with "rt=core.rd;rt=core.rd-lookup-res;core.rd-lookup-ep" etc. would be registered in an RD and exported to DNS-SD. Other RD services in the network would expose links 
> to the RD services that were discovered over DNS-SD. In this way, all of the RD services that are only reachable using unicast could be discovered in "local" RD services. 
> DNS-SD would be used to keep all of the RD service locations discoverable through RD on local network scope.

> Based on these discussion, I am recommending that the DNS-SD mapping to RD links be taken up in a separate document, to normatively refer to the RD document, 
> and be published in the same time frame in order to enable systems to use both RD and DNS-SD together.

After all, making a RD server discoverable as DNS/DNS-SD service does not bread the existing rules or add anything new to the existing Internet nodes.  
For the a RD server as a node fuctioning for resolution, it is tied to DNS/DNS-SD, but it works only for CoAP node or resource resolution. 

Regards, 

Gengyu WEI
Network Technology Center
School of Computer 
Beijing University of Posts and Telecommunications

From: Michael Koster 
Sent: Friday, April 07, 2017 11:03 PM
To: Kerry Lynn ; peter van der Stok ; Carsten Bormann ; Zach Shelby ; Jaime Jiménez ; Christian Amsüss 
Cc: [email-masked] ; core 
Subject: [core] Continuing the Resource Directory and DNS-SD discussion

Hi, 

There is a github repository with this work in progress and issues tracking:
RD document: https://github.com/core-wg/resource-directory
RD to DNS-SD mapping document: https://github.com/core-wg/rd-dns-sd

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