idnits 2.17.1 draft-ietf-core-rd-dns-sd-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 03, 2017) is 2482 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-28) exists of draft-ietf-core-resource-directory-10 ** Obsolete normative reference: RFC 5988 (Obsoleted by RFC 8288) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CoRE K. Lynn 3 Internet-Draft Verizon Labs 4 Intended status: Standards Track P. van der Stok 5 Expires: January 4, 2018 consultant 6 M. Koster 7 SmartThings 8 C. Amsuess, Ed. 9 Energy Harvesting Solutions 10 July 03, 2017 12 CoRE Resource Directory: DNS-SD mapping 13 draft-ietf-core-rd-dns-sd-00 15 Abstract 17 TBD 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on January 4, 2018. 36 Copyright Notice 38 Copyright (c) 2017 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. New Link-Format Attributes . . . . . . . . . . . . . . . . . 3 56 2.1. Resource Instance attribute 'ins' . . . . . . . . . . . . 3 57 2.2. Export attribute 'exp' . . . . . . . . . . . . . . . . . 3 58 3. DNS-SD Mapping . . . . . . . . . . . . . . . . . . . . . . . 4 59 3.1. DNS-based Service discovery . . . . . . . . . . . . . . . 4 60 3.2. mapping ins to . . . . . . . . . . . . . . . . 5 61 3.3. Mapping rt to . . . . . . . . . . . . . . . 5 62 3.4. Domain mapping . . . . . . . . . . . . . . . . . . . . . 6 63 3.5. TXT Record key=value strings . . . . . . . . . . . . . . 6 64 3.6. Importing resource links into DNS-SD . . . . . . . . . . 6 65 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 4.1. DNS entries . . . . . . . . . . . . . . . . . . . . . . . 7 67 5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 8 68 6. Security considerations . . . . . . . . . . . . . . . . . . . 8 69 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 71 7.2. Informative References . . . . . . . . . . . . . . . . . 9 72 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 10 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 75 1. Introduction 77 TBD ... [RFC7252] ... [I-D.ietf-core-resource-directory] ... DNS-SD 79 1.1. Terminology 81 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 82 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 83 "OPTIONAL" in this document are to be interpreted as described in 84 [RFC2119]. The term "byte" is used in its now customary sense as a 85 synonym for "octet". 87 This specification requires readers to be familiar with all the terms 88 and concepts that are discussed in [RFC5988] and [RFC6690]. Readers 89 should also be familiar with the terms and concepts discussed in 90 [RFC7252]. To describe the REST interfaces defined in this 91 specification, the URI Template format is used [RFC6570]. 93 This specification makes use of the terminology of 94 [I-D.ietf-core-resource-directory]. 96 This specification makes use of the following additional terminology: 98 TBD: TBD 100 TBD: TBD 102 2. New Link-Format Attributes 104 When using the CoRE Link Format to describe resources being 105 discovered by or posted to a resource directory service, additional 106 information about those resources is useful. This specification 107 defines the following new attributes for use in the CoRE Link Format 108 [RFC6690]: 110 link-extension = ( "ins" "=" (ptoken | quoted-string) ) 111 ; The token or string is max 63 bytes 112 link-extension = ( "exp" ) 114 2.1. Resource Instance attribute 'ins' 116 The Resource Instance "ins" attribute is an identifier for this 117 resource, which makes it possible to distinguish it from other 118 similar resources. This attribute is similar in use to the 119 portion of a DNS-SD record (see Section 3.1, and SHOULD be 120 unique across resources with the same Resource Type attribute in the 121 domain it is used. A Resource Instance might be a descriptive string 122 like "Ceiling Light, Room 3", a short ID like "AF39" or a unique UUID 123 or iNumber. This attribute is used by a Resource Directory to 124 distinguish between multiple instances of the same resource type 125 within the directory. 127 This attribute MUST be no more than 63 bytes in length. The resource 128 identifier attribute MUST NOT appear more than once in a link 129 description. This attribute MAY be used as a query parameter in the 130 RD Lookup Function Set defined in Section 7. 132 2.2. Export attribute 'exp' 134 The Export "exp" attribute is used as a flag to indicate that a link 135 description MAY be exported by a resource directory to external 136 directories. 138 The CoRE Link Format is used for many purposes between CoAP 139 endpoints. Some are useful mainly locally, for example checking the 140 observability of a resource before accessing it, determining the size 141 of a resource, or traversing dynamic resource structures. However, 142 other links are very useful to be exported to other directories, for 143 example the entry point resource to a functional service. This 144 attribute MAY be used as a query parameter in the RD Lookup Function 145 Set defined in Section 7. 147 3. DNS-SD Mapping 149 CoRE Resource Discovery is intended to support fine-grained discovery 150 of hosted resources, their attributes, and possibly other resource 151 relations [RFC6690]. In contrast, service discovery generally refers 152 to a coarse-grained resolution of an endpoint's IP address, port 153 number, and protocol. 155 Resource and service discovery are complementary in the case of large 156 networks, where the latter can facilitate scaling. This document 157 defines a mapping between CoRE Link Format attributes and DNS-Based 158 Service Discovery [RFC6763] fields that permits discovery of CoAP 159 services by either method. 161 3.1. DNS-based Service discovery 163 DNS-Based Service Discovery (DNS-SD) defines a conventional method of 164 configuring DNS PTR, SRV, and TXT resource records to facilitate 165 discovery of services (such as CoAP servers in a subdomain) using the 166 existing DNS infrastructure. This section gives a brief overview of 167 DNS-SD; see [RFC6763] for a detailed specification. 169 DNS-SD service names are limited to 255 octets and are of the form: 171 Service Name = ... 173 The service name is the label of SRV/TXT resource records. The SRV 174 RR specifies the host and the port of the endpoint. The TXT RR 175 provides additional information in the form of key/value pairs. 177 The part of the service name is identical to the global (DNS 178 subdomain) part of the authority in URIs that identify servers or 179 groups of servers. 181 The part is composed of at least two labels. The first 182 label of the pair is the application protocol name [RFC6335] preceded 183 by an underscore character. The second label indicates the transport 184 and is always "_udp" for UDP-based CoAP services. In cases where 185 narrowing the scope of the search may be useful, these labels may be 186 optionally preceded by a subtype name followed by the "_sub" label. 187 An example of this more specific is 188 "light._sub._dali._udp". 190 A default part of the service name may be set at the 191 factory or during the commissioning process. It SHOULD uniquely 192 identify an instance of within a . Taken 193 together, these three elements comprise a unique name for an SRV/ TXT 194 record pair within the DNS subdomain. 196 The granularity of a service name MAY be that of a host or group, or 197 it could represent a particular resource within a CoAP server. The 198 SRV record contains the host name (AAAA record name) and port of the 199 service while protocol is part of the service name. In the case 200 where a service name identifies a particular resource, the path part 201 of the URI must be carried in a corresponding TXT record. 203 A DNS TXT record is in practice limited to a few hundred octets in 204 length, which is indicated in the resource record header in the DNS 205 response message. The data consists of one or more strings 206 comprising a key=value pair. By convention, the first pair is 207 txtver= (to support different versions of a service 208 description). 210 3.2. mapping ins to 212 The Resource Instance "ins" attribute maps to the part of 213 a DNS-SD service name. It is stored directly in the DNS as a single 214 DNS label of canonical precomposed UTF-8 [RFC3629] "Net-Unicode" 215 (Unicode Normalization Form C) [RFC5198] text. However, to the 216 extent that the "ins" attribute may be chosen to match the DNS host 217 name of a service, it SHOULD use the syntax defined in Section 3.5 of 218 [RFC1034] and Section 2.1 of [RFC1123]. 220 The part of the name of a service being offered on the 221 network SHOULD be configurable by the user setting up the service, so 222 that he or she may give it an informative name. However, the device 223 or service SHOULD NOT require the user to configure a name before it 224 can be used. A sensible choice of default name can allow the device 225 or service to be accessed in many cases without any manual 226 configuration at all. The default name should be short and 227 descriptive, and MAY include a collision-resistant substring such as 228 the lower bits of the device's MAC address, serial number, 229 fingerprint, or other identifier in an attempt to make the name 230 relatively unique. 232 DNS labels are currently limited to 63 octets in length and the 233 entire service name may not exceed 255 octets. 235 3.3. Mapping rt to 237 The resource type "rt" attribute is mapped into the 238 part of a DNS-SD service name and SHOULD conform to the reg-rel-type 239 production of the Link Format defined in Section 2 of [RFC6690]. The 240 "rt" attribute MUST be composed of at least a single Net-Unicode text 241 string, without underscore '_' or period '.' and limited to 15 octets 242 in length, which represents the application protocol name. This 243 string is mapped to the DNS-SD by prepending an 244 underscore and appending a period followed by the "_udp" label. For 245 example, rt="dali" is mapped into "_dali._udp". 247 The application protocol name may be optionally followed by a period 248 and a service subtype name consisting of a Net-Unicode text string, 249 without underscore or period and limited to 63 octets. This string 250 is mapped to the DNS-SD by appending a period followed 251 by the "_sub" label and then appending a period followed by the 252 service type label pair derived as in the previous paragraph. For 253 example, rt="dali.light" is mapped into "light._sub._dali._udp". 255 The resulting string is used to form labels for DNS-SD records which 256 are stored directly in the DNS. 258 3.4. Domain mapping 260 DNS domains may be derived from the "d" attribute. The domain 261 attribute may be suffixed with the zone name of the authoritative DNS 262 server to generate the domain name. The "ep" attribute is prefixed 263 to the domain name to generate the FQDN to be stored into DNS with an 264 AAAA RR. 266 3.5. TXT Record key=value strings 268 A number of [RFC6763] key/value pairs are derived from link-format 269 information, to be exported in the DNS-SD as key=value strings in a 270 TXT record ([RFC6763], Section 6.3). 272 The resource is exported as key/value pair "path=". 274 The Interface Description "if" attribute is exported as key/value 275 pair "if=". 277 The DNS TXT record can be further populated by importing any other 278 resource description attributes as they share the same key=value 279 format specified in Section 6 of [RFC6763]. 281 3.6. Importing resource links into DNS-SD 283 Assuming the ability to query a Resource Directory or multicast a GET 284 (?exp) over the local link, CoAP resource discovery may be used to 285 populate the DNS-SD database in an automated fashion. CoAP resource 286 descriptions (links) can be exported to DNS-SD for exposure to 287 service discovery by using the Resource Instance attribute as the 288 basis for a unique service name, composed with the Resource Type as 289 the , and registered in the correct . The agent 290 responsible for exporting records to the DNS zone file SHOULD be 291 authenticated to the DNS server. The following example, using the 292 example lookup location /rd-lookup, shows an agent discovering a 293 resource to be exported: 295 Req: GET /rd-lookup/res?exp 297 Res: 2.05 Content 298 ; 299 exp;rt="dali.light";ins="Spot"; 300 d="office";ep="node1" 302 The agent subsequently registers the following DNS-SD RRs, assuming a 303 zone name "example.com" prefixed with "office": 305 node1.office.example.com. IN AAAA FDFD::1234 306 _dali._udp.office.example.com IN PTR 307 Spot._dali._udp.office.example.com 308 light._sub._dali._udp.example.com IN PTR 309 Spot._dali._udp.office.example.com 310 Spot._dali._udp.office.example.com IN SRV 0 0 5683 311 node1.office.example.com. 312 Spot._dali._udp.office.example.com IN TXT 313 txtver=1;path=/light/1 315 In the above figure the Service Name is chosen as 316 Spot._dali._udp.office.example.com without the light._sub service 317 prefix. An alternative Service Name would be: 318 Spot.light._sub._dali._udp.office.example.com. 320 4. Examples 322 4.1. DNS entries 324 It may be profitable to discover the light groups for applications, 325 which are unaware ot the existence of the RD. An agent needs to 326 query the RD to return all groups which are exported to be inserted 327 into DNS. 329 Req: GET /rd-lookup/gp?exp 331 Res: 2.05 Content 332 ;exp;gp="grp_R2-4-015;ins="grp1234"; 333 ep="lm_R2-4-015_wndw"; 334 ep="lm_R2-4-015_door 336 The group with FQDN grp_R2-4-015.bc.example.com can be entered into 337 the DNS by the agent. The accompanying instance name is grp1234. 338 The is chosen to be _group._udp. The agent enters the 339 following RRs into the DNS. 341 grp_R2-4-015.bc.example.com. IN AAAA FF05::1 342 _group._udp.bc.example.com IN PTR 343 grp1234._group._udp.bc.example.com 344 grp1234._group._udp.bc.example.com IN SRV 0 0 5683 345 grp_R2-4-015_door.bc.example.com. 346 grp1234._group._udp.bc.example.com IN TXT 347 txtver=1;path=/light/grp1 349 From then on applications, not familiar with the existence of the RD, 350 can use DNS to access the lighting group. 352 5. IANA considerations 354 TBD 356 6. Security considerations 358 TBD 360 7. References 362 7.1. Normative References 364 [I-D.ietf-core-resource-directory] 365 Shelby, Z., Koster, M., Bormann, C., and P. Stok, "CoRE 366 Resource Directory", draft-ietf-core-resource-directory-10 367 (work in progress), March 2017. 369 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 370 Requirement Levels", BCP 14, RFC 2119, 371 DOI 10.17487/RFC2119, March 1997, 372 . 374 [RFC5988] Nottingham, M., "Web Linking", RFC 5988, 375 DOI 10.17487/RFC5988, October 2010, 376 . 378 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 379 Cheshire, "Internet Assigned Numbers Authority (IANA) 380 Procedures for the Management of the Service Name and 381 Transport Protocol Port Number Registry", BCP 165, 382 RFC 6335, DOI 10.17487/RFC6335, August 2011, 383 . 385 [RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., 386 and D. Orchard, "URI Template", RFC 6570, 387 DOI 10.17487/RFC6570, March 2012, 388 . 390 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 391 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 392 . 394 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 395 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 396 . 398 7.2. Informative References 400 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 401 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 402 . 404 [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - 405 Application and Support", STD 3, RFC 1123, 406 DOI 10.17487/RFC1123, October 1989, 407 . 409 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 410 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 411 2003, . 413 [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network 414 Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008, 415 . 417 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 418 Application Protocol (CoAP)", RFC 7252, 419 DOI 10.17487/RFC7252, June 2014, 420 . 422 Acknowledgements 424 This document was split off from [I-D.ietf-core-resource-directory]. 425 TODO: Copy over relevant acknowledgements. 427 Authors' Addresses 429 Kerry Lynn 430 Verizon Labs 431 50 Sylvan Rd 432 Waltham, MA 02451 433 USA 435 Phone: +1 781 296 9722 436 Email: kerlyn@ieee.org 438 Peter van der Stok 439 consultant 441 Phone: +31-492474673 (Netherlands), +33-966015248 (France) 442 Email: consultancy@vanderstok.org 443 URI: www.vanderstok.org 445 Michael Koster 446 SmartThings 447 665 Clyde Avenue 448 Mountain View 94043 449 USA 451 Phone: +1-707-502-5136 452 Email: Michael.Koster@smartthings.com 454 Christian Amsuess (editor) 455 Energy Harvesting Solutions 456 Hollandstr. 12/4 457 1020 458 Austria 460 Phone: +43-664-9790639 461 Email: c.amsuess@energyharvesting.at