draft-ietf-core-rd-dns-sd-00.txt   draft-ietf-core-rd-dns-sd-01.txt 
CoRE K. Lynn CoRE K. Lynn
Internet-Draft Verizon Labs Internet-Draft P. van der Stok
Intended status: Standards Track P. van der Stok Intended status: Standards Track Consultants
Expires: January 4, 2018 consultant Expires: September 6, 2018 M. Koster
M. Koster
SmartThings SmartThings
C. Amsuess, Ed. C. Amsuess
Energy Harvesting Solutions Energy Harvesting Solutions
July 03, 2017 March 05, 2018
CoRE Resource Directory: DNS-SD mapping CoRE Resource Directory: DNS-SD mapping
draft-ietf-core-rd-dns-sd-00 draft-ietf-core-rd-dns-sd-01
Abstract Abstract
TBD Resource and service discovery are complimentary. Resource discovery
provides fine-grained detail about the content of a server, while
service discovery can provide a scalable method to locate servers in
large networks. This document defines a method for mapping between
CoRE Link Format attributes and DNS-Based Service Discovery fields to
facilitate the use of either method to locate RESTful service
interfaces (APIs) in mixed HTTP/CoAP environments.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 4, 2018. This Internet-Draft will expire on September 6, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. New Link-Format Attributes . . . . . . . . . . . . . . . . . 3 1.2. Resource Discovery . . . . . . . . . . . . . . . . . . . 3
2.1. Resource Instance attribute 'ins' . . . . . . . . . . . . 3 1.3. Resource Directories . . . . . . . . . . . . . . . . . . 4
2.2. Export attribute 'exp' . . . . . . . . . . . . . . . . . 3 1.4. DNS-Based Service Discovery . . . . . . . . . . . . . . . 4
3. DNS-SD Mapping . . . . . . . . . . . . . . . . . . . . . . . 4 2. New Link-Format Attributes . . . . . . . . . . . . . . . . . 5
3.1. DNS-based Service discovery . . . . . . . . . . . . . . . 4 2.1. Resource Instance attribute "ins" . . . . . . . . . . . . 6
3.2. mapping ins to <Instance> . . . . . . . . . . . . . . . . 5 2.2. Export attribute "exp" . . . . . . . . . . . . . . . . . 6
3.3. Mapping rt to <ServiceType> . . . . . . . . . . . . . . . 5 3. Mapping CoRE Link Attributes to DNS-SD Record Fields . . . . 6
3.4. Domain mapping . . . . . . . . . . . . . . . . . . . . . 6 3.1. Mapping Resource Instance attribute "ins" to <Instance> . 6
3.5. TXT Record key=value strings . . . . . . . . . . . . . . 6 3.2. Mapping Resource Type attribute "rt" to <ServiceType> . . 7
3.6. Importing resource links into DNS-SD . . . . . . . . . . 6 3.3. Domain mapping . . . . . . . . . . . . . . . . . . . . . 7
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.4. TXT Record key=value strings . . . . . . . . . . . . . . 7
4.1. DNS entries . . . . . . . . . . . . . . . . . . . . . . . 7 3.5. Importing resource links into DNS-SD . . . . . . . . . . 8
5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 8 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6. Security considerations . . . . . . . . . . . . . . . . . . . 8 4.1. DNS entries . . . . . . . . . . . . . . . . . . . . . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 9
7.1. Normative References . . . . . . . . . . . . . . . . . . 8 6. Security considerations . . . . . . . . . . . . . . . . . . . 9
7.2. Informative References . . . . . . . . . . . . . . . . . 9 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 10 7.1. Normative References . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 7.2. Informative References . . . . . . . . . . . . . . . . . 10
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
TBD ... [RFC7252] ... [I-D.ietf-core-resource-directory] ... DNS-SD The Constrained RESTful Environments (CoRE) working group aims at
realizing the REST architecture in a suitable form for the most
constrained devices (e.g. 8-bit microcontrollers with limited RAM and
ROM) and networks (e.g. 6LoWPAN). CoRE is aimed at machine-to-
machine (M2M) applications such as smart energy and building
automation. The main deliverable of CoRE is the Constrained
Application Protocol (CoAP) specification [RFC7252].
Automated discovery of resources hosted by a constrained server is
critical in M2M applications where human intervention is minimal and
static interfaces result in brittleness. CoRE Resource Discovery is
intended to support fine-grained discovery of hosted resources, their
attributes, and possibly other resource relations [RFC6690].
In contrast, service discovery generally refers to a coarse-grained
resolution of an end-point's IP address, port number, and protocol.
This definition may be extended to include multi-function devices,
where the result of the discovery process may include a path to a
resource representing a RESTful service interface and possibly a
reference to a description of the interface such as a JSON Hyper-
Schema document [I-D.handrews-json-schema-hyperschema].
Resource and service discovery are complimentary in the case of large
networks, where the latter can facilitate scaling. This document
defines a mapping between CoRE Link Format attributes and DNS-Based
Service Discovery (DNS-SD) [RFC6763] fields that permits discovery of
CoAP services by either means. It also addresses the CoRE charter
goal to interoperate with DNS-SD.
1.1. Terminology 1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. The term "byte" is used in its now customary sense as a [RFC2119]. The term "byte" is used in its now customary sense as a
synonym for "octet". synonym for "octet".
This specification requires readers to be familiar with all the terms This specification requires readers to be familiar with all the terms
and concepts that are discussed in [RFC5988] and [RFC6690]. Readers and concepts that are discussed in {-link} and [RFC6690]. Readers
should also be familiar with the terms and concepts discussed in should also be familiar with the terms and concepts discussed in
[RFC7252]. To describe the REST interfaces defined in this [RFC7252]. To describe the REST interfaces defined in this
specification, the URI Template format is used [RFC6570]. specification, the URI Template format is used [RFC6570].
This specification makes use of the terminology of This specification also makes use of the terminology of
[I-D.ietf-core-resource-directory]. [I-D.ietf-core-resource-directory].
This specification makes use of the following additional terminology: 1.2. Resource Discovery
TBD: TBD The main function of Resource Discovery is to provide Universal
Resource Identifiers (URIs, also called "links") for the resources
hosted by the server, complemented by attributes about those
resources and perhaps additional link relations. In CoRE this
collection of links and attributes is itself a resource (as opposed
to HTTP headers delivered with a specific resource).
TBD: TBD [RFC6690] specifies a link format for use in CoRE Resource Discovery
by extending the HTTP Link Header Format [RFC8288] to describe these
link descriptions. The CoRE Link Format is carried as a payload and
is assigned an Internet media type. A well-known URI "/.well-known/
core" is defined as a default entry-point for requesting the list of
links about resources hosted by a server, and thus performing CoRE
Resource Discovery.
Resource Discovery can be performed either via unicast or multicast.
When a server's IP address is already known, either a priori or
resolved via the Domain Name System (DNS) [RFC1034][RFC1035], unicast
discovery is performed in order to locate a URI for the resource of
interest. This is performed using a GET to /.well-known/core on the
server, which returns a payload in the CoRE Link Format. A client
would then match the appropriate Resource Type, Interface
Description, and possible Content-Type [RFC2045] for its application.
These attributes may also be included in the query string in order to
filter the number of links returned in a response.
1.3. Resource Directories
In many M2M scenarios, direct discovery of resources is not practical
due to sleeping nodes, limited bandwidth, or networks where multicast
traffic is inefficient. These problems can be solved by deploying a
network element called a Resource Directory (RD), which hosts
descriptions of resources held on other servers (referred to as "end-
points") and allows lookups to be performed for those resources. An
end-point is a web server associated with specific IP address and
port; thus a physical device may host one or more end-points. End-
points may also act as clients.
The Resource Directory implements a set of REST interfaces for end-
points to register and maintain sets of Web Links, called resource
directory entries. [I-D.ietf-core-resource-directory] specifies the
web interfaces that an RD supports in order for web servers to
discover the RD and to register, maintain, lookup and remove resource
descriptions; for the RD to validate entries; and for clients to
lookup resources from the RD. Furthermore, new link attributes
useful in conjunction with an RD are defined.
1.4. DNS-Based Service Discovery
DNS-Based Service Discovery (DNS-SD) defines a conventional method of
configuring DNS PTR, SRV, and TXT resource records to facilitate
discovery of services (such as CoAP servers in a subdomain) using the
existing DNS infrastructure. This section gives a brief overview of
DNS-SD; see [RFC6763] for a detailed specification.
DNS-SD service names are limited to 255 bytes and are of the form:
Service Name = <Instance>.<ServiceType>.<Domain>
The service name is the label of SRV/TXT resource records. The SRV
RR specifies the host and the port of the endpoint. The TXT RR
provides additional information in the form of key/value pairs.
The <Domain> part of the service name is identical to the global (DNS
subdomain) part of the authority in URIs that identify the resources
on an individual server or group of servers.
The <ServiceType> part is composed of at least two labels. The first
label of the pair is the application protocol name [RFC6335] preceded
by an underscore character. The second label indicates the transport
and is always "_udp" for CoAP services. In cases where narrowing the
scope of the search may be useful, these labels may be optionally
preceded by a subtype name followed by the "_sub" label. An example
of this more specific <ServiceType> is "lamp._sub._dali._udp". Only
the rightmost pair of labels is used in SRV and TXT record names.
The default <Instance> part of the service name may be set at the
factory or during the commissioning process. It SHOULD uniquely
identify an instance of <ServiceType> within a <Domain>. Taken
together, these three elements comprise a unique name for an SRV/ TXT
record pair within the DNS subdomain.
The granularity of a service name MAY be that of a host or group, or
it could represent a particular resource within a CoAP server. The
SRV record contains the host name (AAAA record name) and port of the
service while protocol is part of the service name. In the case
where a service name identifies a particular resource, the path part
of the URI must be carried in a corresponding TXT record.
A DNS TXT record is in practice limited to a few hundred bytes in
length, which is indicated in the resource record header in the DNS
response message [RFC6763]. The data consists of one or more strings
comprising a key=value pair. By convention, the first pair is
txtver=<number> (to support different versions of a service
description). An example string is:
| 0x08 | t | x | t | v | e | r | = | 1 |
2. New Link-Format Attributes 2. New Link-Format Attributes
When using the CoRE Link Format to describe resources being When using the CoRE Link Format to describe resources being
discovered by or posted to a resource directory service, additional discovered by or posted to a resource directory service, additional
information about those resources is useful. This specification information about those resources is useful. This specification
defines the following new attributes for use in the CoRE Link Format defines the following new attributes for use in the CoRE Link Format
[RFC6690]: [RFC6690]:
link-extension = ( "ins" "=" (ptoken | quoted-string) ) link-extension = ( "ins" "=" (ptoken | quoted-string) )
; The token or string is max 63 bytes ; The token or string is max 63 bytes
link-extension = ( "exp" ) link-extension = ( "exp" )
2.1. Resource Instance attribute 'ins' 2.1. Resource Instance attribute "ins"
The Resource Instance "ins" attribute is an identifier for this The Resource Instance "ins" attribute is an identifier for this
resource, which makes it possible to distinguish it from other resource, which makes it possible to distinguish it from other
similar resources. This attribute is similar in use to the similar resources. This attribute is similar in use to the
<Instance> portion of a DNS-SD record (see Section 3.1, and SHOULD be <Instance> portion of a DNS-SD record (see Section 1.4, and SHOULD be
unique across resources with the same Resource Type attribute in the unique across resources with the same Resource Type attribute in the
domain it is used. A Resource Instance might be a descriptive string domain it is used. A Resource Instance might be a descriptive string
like "Ceiling Light, Room 3", a short ID like "AF39" or a unique UUID like "Ceiling Light, Room 3", a short ID like "AF39" or a unique UUID
or iNumber. This attribute is used by a Resource Directory to or iNumber. This attribute is used by a Resource Directory to
distinguish between multiple instances of the same resource type distinguish between multiple instances of the same resource type
within the directory. within the directory.
This attribute MUST be no more than 63 bytes in length. The resource This attribute MUST be no more than 63 bytes in length. The resource
identifier attribute MUST NOT appear more than once in a link identifier attribute MUST NOT appear more than once in a link
description. This attribute MAY be used as a query parameter in the description. This attribute MAY be used as a query parameter in the
RD Lookup Function Set defined in Section 7. RD Lookup Function Set defined in Section 7 of
[I-D.ietf-core-resource-directory].
2.2. Export attribute 'exp' 2.2. Export attribute "exp"
The Export "exp" attribute is used as a flag to indicate that a link The Export "exp" attribute is used as a flag to indicate that a link
description MAY be exported by a resource directory to external description MAY be exported by a resource directory to external
directories. directories.
The CoRE Link Format is used for many purposes between CoAP The CoRE Link Format is used for many purposes between CoAP
endpoints. Some are useful mainly locally, for example checking the endpoints. Some are useful mainly locally, for example checking the
observability of a resource before accessing it, determining the size observability of a resource before accessing it, determining the size
of a resource, or traversing dynamic resource structures. However, of a resource, or traversing dynamic resource structures. However,
other links are very useful to be exported to other directories, for other links are very useful to be exported to other directories, for
example the entry point resource to a functional service. This example the entry point resource to a functional service. This
attribute MAY be used as a query parameter in the RD Lookup Function attribute MAY be used as a query parameter in the RD Lookup Function
Set defined in Section 7. Set defined in Section 7 of [I-D.ietf-core-resource-directory].
3. DNS-SD Mapping
CoRE Resource Discovery is intended to support fine-grained discovery
of hosted resources, their attributes, and possibly other resource
relations [RFC6690]. In contrast, service discovery generally refers
to a coarse-grained resolution of an endpoint's IP address, port
number, and protocol.
Resource and service discovery are complementary in the case of large
networks, where the latter can facilitate scaling. This document
defines a mapping between CoRE Link Format attributes and DNS-Based
Service Discovery [RFC6763] fields that permits discovery of CoAP
services by either method.
3.1. DNS-based Service discovery
DNS-Based Service Discovery (DNS-SD) defines a conventional method of
configuring DNS PTR, SRV, and TXT resource records to facilitate
discovery of services (such as CoAP servers in a subdomain) using the
existing DNS infrastructure. This section gives a brief overview of
DNS-SD; see [RFC6763] for a detailed specification.
DNS-SD service names are limited to 255 octets and are of the form:
Service Name = <Instance>.<ServiceType>.<Domain>.
The service name is the label of SRV/TXT resource records. The SRV
RR specifies the host and the port of the endpoint. The TXT RR
provides additional information in the form of key/value pairs.
The <Domain> part of the service name is identical to the global (DNS
subdomain) part of the authority in URIs that identify servers or
groups of servers.
The <ServiceType> part is composed of at least two labels. The first
label of the pair is the application protocol name [RFC6335] preceded
by an underscore character. The second label indicates the transport
and is always "_udp" for UDP-based CoAP services. In cases where
narrowing the scope of the search may be useful, these labels may be
optionally preceded by a subtype name followed by the "_sub" label.
An example of this more specific <ServiceType> is
"light._sub._dali._udp".
A default <Instance> part of the service name may be set at the
factory or during the commissioning process. It SHOULD uniquely
identify an instance of <ServiceType> within a <Domain>. Taken
together, these three elements comprise a unique name for an SRV/ TXT
record pair within the DNS subdomain.
The granularity of a service name MAY be that of a host or group, or
it could represent a particular resource within a CoAP server. The
SRV record contains the host name (AAAA record name) and port of the
service while protocol is part of the service name. In the case
where a service name identifies a particular resource, the path part
of the URI must be carried in a corresponding TXT record.
A DNS TXT record is in practice limited to a few hundred octets in 3. Mapping CoRE Link Attributes to DNS-SD Record Fields
length, which is indicated in the resource record header in the DNS
response message. The data consists of one or more strings
comprising a key=value pair. By convention, the first pair is
txtver=<number> (to support different versions of a service
description).
3.2. mapping ins to <Instance> 3.1. Mapping Resource Instance attribute "ins" to <Instance>
The Resource Instance "ins" attribute maps to the <Instance> part of The Resource Instance "ins" attribute maps to the <Instance> part of
a DNS-SD service name. It is stored directly in the DNS as a single a DNS-SD service name. It is stored directly in the DNS as a single
DNS label of canonical precomposed UTF-8 [RFC3629] "Net-Unicode" DNS label of canonical precomposed UTF-8 [RFC3629] "Net-Unicode"
(Unicode Normalization Form C) [RFC5198] text. However, to the (Unicode Normalization Form C) [RFC5198] text. However, to the
extent that the "ins" attribute may be chosen to match the DNS host extent that the "ins" attribute may be chosen to match the DNS host
name of a service, it SHOULD use the syntax defined in Section 3.5 of name of a service, it SHOULD use the syntax defined in Section 3.5 of
[RFC1034] and Section 2.1 of [RFC1123]. [RFC1034] and Section 2.1 of [RFC1123].
The <Instance> part of the name of a service being offered on the The <Instance> part of the name of a service being offered on the
skipping to change at page 5, line 44 skipping to change at page 7, line 14
that he or she may give it an informative name. However, the device that he or she may give it an informative name. However, the device
or service SHOULD NOT require the user to configure a name before it or service SHOULD NOT require the user to configure a name before it
can be used. A sensible choice of default name can allow the device can be used. A sensible choice of default name can allow the device
or service to be accessed in many cases without any manual or service to be accessed in many cases without any manual
configuration at all. The default name should be short and configuration at all. The default name should be short and
descriptive, and MAY include a collision-resistant substring such as descriptive, and MAY include a collision-resistant substring such as
the lower bits of the device's MAC address, serial number, the lower bits of the device's MAC address, serial number,
fingerprint, or other identifier in an attempt to make the name fingerprint, or other identifier in an attempt to make the name
relatively unique. relatively unique.
DNS labels are currently limited to 63 octets in length and the DNS labels are currently limited to 63 bytes in length and the entire
entire service name may not exceed 255 octets. service name may not exceed 255 bytes.
3.3. Mapping rt to <ServiceType> 3.2. Mapping Resource Type attribute "rt" to <ServiceType>
The resource type "rt" attribute is mapped into the <ServiceType> The resource type "rt" attribute is mapped into the <ServiceType>
part of a DNS-SD service name and SHOULD conform to the reg-rel-type part of a DNS-SD service name and SHOULD conform to the reg-rel-type
production of the Link Format defined in Section 2 of [RFC6690]. The production of the Link Format defined in Section 2 of [RFC6690]. The
"rt" attribute MUST be composed of at least a single Net-Unicode text "rt" attribute MUST be composed of at least a single Net-Unicode text
string, without underscore '_' or period '.' and limited to 15 octets string, without underscore '_' or period '.' and limited to 15 bytes
in length, which represents the application protocol name. This in length, which represents the application protocol name. This
string is mapped to the DNS-SD <ServiceType> by prepending an string is mapped to the DNS-SD <ServiceType> by prepending an
underscore and appending a period followed by the "_udp" label. For underscore and appending a period followed by the "_udp" label. For
example, rt="dali" is mapped into "_dali._udp". example, rt="dali" is mapped into "_dali._udp".
The application protocol name may be optionally followed by a period The application protocol name may be optionally followed by a period
and a service subtype name consisting of a Net-Unicode text string, and a service subtype name consisting of a Net-Unicode text string,
without underscore or period and limited to 63 octets. This string without underscore or period and limited to 63 bytes. This string is
is mapped to the DNS-SD <ServiceType> by appending a period followed mapped to the DNS-SD <ServiceType> by appending a period followed by
by the "_sub" label and then appending a period followed by the the "_sub" label and then appending a period followed by the service
service type label pair derived as in the previous paragraph. For type label pair derived as in the previous paragraph. For example,
example, rt="dali.light" is mapped into "light._sub._dali._udp". rt="dali.light" is mapped into "light._sub._dali._udp".
The resulting string is used to form labels for DNS-SD records which The resulting string is used to form labels for DNS-SD records which
are stored directly in the DNS. are stored directly in the DNS.
3.4. Domain mapping 3.3. Domain mapping
DNS domains may be derived from the "d" attribute. The domain TBD: A method must be specified to determine in which DNS zone the
attribute may be suffixed with the zone name of the authoritative DNS CoAP service should be registered. See, for example, Section 11 in
server to generate the domain name. The "ep" attribute is prefixed [RFC6763].
to the domain name to generate the FQDN to be stored into DNS with an
AAAA RR.
3.5. TXT Record key=value strings 3.4. TXT Record key=value strings
A number of [RFC6763] key/value pairs are derived from link-format A number of [RFC6763] key/value pairs are derived from link-format
information, to be exported in the DNS-SD as key=value strings in a information, to be exported in the DNS-SD as key=value strings in a
TXT record ([RFC6763], Section 6.3). TXT record ([RFC6763], Section 6.3).
The resource <URI> is exported as key/value pair "path=<URI>". The resource <URI> is exported as key/value pair "path=<URI>".
The Interface Description "if" attribute is exported as key/value The Interface Description "if" attribute is exported as key/value
pair "if=<Interface Description>". pair "if=<Interface Description>".
The DNS TXT record can be further populated by importing any other The DNS TXT record can be further populated by importing any other
resource description attributes as they share the same key=value resource description attributes as they share the same key=value
format specified in Section 6 of [RFC6763]. format specified in Section 6 of [RFC6763].
3.6. Importing resource links into DNS-SD 3.5. Importing resource links into DNS-SD
Assuming the ability to query a Resource Directory or multicast a GET Assuming the ability to query a Resource Directory or multicast a GET
(?exp) over the local link, CoAP resource discovery may be used to (?exp) over the local link, CoAP resource discovery may be used to
populate the DNS-SD database in an automated fashion. CoAP resource populate the DNS-SD database in an automated fashion. CoAP resource
descriptions (links) can be exported to DNS-SD for exposure to descriptions (links) can be exported to DNS-SD for exposure to
service discovery by using the Resource Instance attribute as the service discovery by using the Resource Instance attribute as the
basis for a unique service name, composed with the Resource Type as basis for a unique service name, composed with the Resource Type as
the <ServiceType>, and registered in the correct <Domain>. The agent the <ServiceType>, and registered in the correct <Domain>. The agent
responsible for exporting records to the DNS zone file SHOULD be responsible for exporting records to the DNS zone file SHOULD be
authenticated to the DNS server. The following example, using the authenticated to the DNS server. The following example, using the
skipping to change at page 8, line 25 skipping to change at page 9, line 34
following RRs into the DNS. following RRs into the DNS.
grp_R2-4-015.bc.example.com. IN AAAA FF05::1 grp_R2-4-015.bc.example.com. IN AAAA FF05::1
_group._udp.bc.example.com IN PTR _group._udp.bc.example.com IN PTR
grp1234._group._udp.bc.example.com grp1234._group._udp.bc.example.com
grp1234._group._udp.bc.example.com IN SRV 0 0 5683 grp1234._group._udp.bc.example.com IN SRV 0 0 5683
grp_R2-4-015_door.bc.example.com. grp_R2-4-015_door.bc.example.com.
grp1234._group._udp.bc.example.com IN TXT grp1234._group._udp.bc.example.com IN TXT
txtver=1;path=/light/grp1 txtver=1;path=/light/grp1
From then on applications, not familiar with the existence of the RD, From then on, applications unaware of the existence of the RD can use
can use DNS to access the lighting group. DNS to access the lighting group.
5. IANA considerations 5. IANA considerations
TBD TBD
6. Security considerations 6. Security considerations
TBD TBD
7. References 7. References
7.1. Normative References 7.1. Normative References
[I-D.ietf-core-resource-directory]
Shelby, Z., Koster, M., Bormann, C., and P. Stok, "CoRE
Resource Directory", draft-ietf-core-resource-directory-10
(work in progress), March 2017.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC5988] Nottingham, M., "Web Linking", RFC 5988,
DOI 10.17487/RFC5988, October 2010,
<http://www.rfc-editor.org/info/rfc5988>.
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
Cheshire, "Internet Assigned Numbers Authority (IANA) Cheshire, "Internet Assigned Numbers Authority (IANA)
Procedures for the Management of the Service Name and Procedures for the Management of the Service Name and
Transport Protocol Port Number Registry", BCP 165, Transport Protocol Port Number Registry", BCP 165,
RFC 6335, DOI 10.17487/RFC6335, August 2011, RFC 6335, DOI 10.17487/RFC6335, August 2011,
<http://www.rfc-editor.org/info/rfc6335>. <https://www.rfc-editor.org/info/rfc6335>.
[RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., [RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M.,
and D. Orchard, "URI Template", RFC 6570, and D. Orchard, "URI Template", RFC 6570,
DOI 10.17487/RFC6570, March 2012, DOI 10.17487/RFC6570, March 2012,
<http://www.rfc-editor.org/info/rfc6570>. <https://www.rfc-editor.org/info/rfc6570>.
[RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link
Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, Format", RFC 6690, DOI 10.17487/RFC6690, August 2012,
<http://www.rfc-editor.org/info/rfc6690>. <https://www.rfc-editor.org/info/rfc6690>.
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
<http://www.rfc-editor.org/info/rfc6763>. <https://www.rfc-editor.org/info/rfc6763>.
[RFC8288] Nottingham, M., "Web Linking", RFC 8288,
DOI 10.17487/RFC8288, October 2017,
<https://www.rfc-editor.org/info/rfc8288>.
7.2. Informative References 7.2. Informative References
[I-D.handrews-json-schema-hyperschema]
Andrews, H. and A. Wright, "JSON Hyper-Schema: A
Vocabulary for Hypermedia Annotation of JSON", draft-
handrews-json-schema-hyperschema-01 (work in progress),
January 2018.
[I-D.ietf-core-resource-directory]
Shelby, Z., Koster, M., Bormann, C., Stok, P., and C.
Amsuess, "CoRE Resource Directory", draft-ietf-core-
resource-directory-13 (work in progress), March 2018.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<http://www.rfc-editor.org/info/rfc1034>. <https://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts -
Application and Support", STD 3, RFC 1123, Application and Support", STD 3, RFC 1123,
DOI 10.17487/RFC1123, October 1989, DOI 10.17487/RFC1123, October 1989,
<http://www.rfc-editor.org/info/rfc1123>. <https://www.rfc-editor.org/info/rfc1123>.
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996,
<https://www.rfc-editor.org/info/rfc2045>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <http://www.rfc-editor.org/info/rfc3629>. 2003, <https://www.rfc-editor.org/info/rfc3629>.
[RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network
Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008, Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008,
<http://www.rfc-editor.org/info/rfc5198>. <https://www.rfc-editor.org/info/rfc5198>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252, Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014, DOI 10.17487/RFC7252, June 2014,
<http://www.rfc-editor.org/info/rfc7252>. <https://www.rfc-editor.org/info/rfc7252>.
Acknowledgements Acknowledgements
This document was split off from [I-D.ietf-core-resource-directory]. This document was split out from [I-D.ietf-core-resource-directory].
TODO: Copy over relevant acknowledgements. Zach Shelby was a co-author of the original version of this draft.
Authors' Addresses Authors' Addresses
Kerry Lynn Kerry Lynn
Verizon Labs Consultant
50 Sylvan Rd
Waltham, MA 02451
USA
Phone: +1 781 296 9722 Phone: +1 978-460-4253
Email: kerlyn@ieee.org Email: kerlyn@ieee.org
Peter van der Stok Peter van der Stok
consultant Consultant
Phone: +31-492474673 (Netherlands), +33-966015248 (France) Phone: +31 492474673 (Netherlands), +33 966015248 (France)
Email: consultancy@vanderstok.org Email: consultancy@vanderstok.org
URI: www.vanderstok.org URI: www.vanderstok.org
Michael Koster Michael Koster
SmartThings SmartThings
665 Clyde Avenue 665 Clyde Avenue
Mountain View 94043 Mountain View 94043
USA USA
Phone: +1-707-502-5136 Phone: +1 707-502-5136
Email: Michael.Koster@smartthings.com Email: Michael.Koster@smartthings.com
Christian Amsuess (editor) Christian Amsuess
Energy Harvesting Solutions Energy Harvesting Solutions
Hollandstr. 12/4 Hollandstr. 12/4
1020 1020
Austria Austria
Phone: +43-664-9790639 Phone: +43 664-9790639
Email: c.amsuess@energyharvesting.at Email: c.amsuess@energyharvesting.at
 End of changes. 53 change blocks. 
157 lines changed or deleted 234 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/