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

[Michael Koster]

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.

[peter van der Stok]

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.

Post by Michael Koster
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.

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

Post by Michael Koster
At IETF 98 we had two discussions..
- 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.

Post by Michael Koster
- 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.

Post by Michael Koster
- 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.

Post by Michael Koster
- 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?

Post by Michael Koster
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

I prefer fine grained versus coarse grained.

Post by Michael Koster
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.

Post by Michael Koster
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.

Post by Michael Koster
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

Post by Michael Koster
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.

Post by Michael Koster
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?

Post by Michael Koster
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

Post by Michael Koster
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.

Post by Michael Koster
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

[weigengyu]

Hi Michael,

We are also intersted in this topic.

Post by Michael Koster
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.

Post by Michael Koster
2. Providing "ins" and "exp" link attributes

Yes.

Post by Michael Koster
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?

Post by Michael Koster
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.

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

Post by Michael Koster
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.

Yes. But DNS or DNS-SD have the data of the “registered” RD server(s), and knows which RD to have.

Post by Michael Koster
- 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

Post by Michael Koster
- 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.

Post by Michael Koster
- 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.

Post by Michael Koster
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.

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.

Post by Michael Koster
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.
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.

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: draft-ietf-core-resource-***@ietf.org ; core
Subject: [core] Continuing the Resource Directory and DNS-SD discussion

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
RD to DNS-SD mapping document: 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.






--------------------------------------------------------------------------------