idnits 2.17.1 draft-lynn-core-discovery-mapping-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 04, 2011) is 4680 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) == Missing Reference: 'TBD' is mentioned on line 256, but not defined == Unused Reference: 'RFC0020' is defined on line 267, but no explicit reference was found in the text == Unused Reference: 'RFC2782' is defined on line 279, but no explicit reference was found in the text == Unused Reference: 'I-D.shelby-core-resource-directory' is defined on line 309, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5988 (Obsoleted by RFC 8288) == Outdated reference: A later version (-11) exists of draft-cheshire-dnsext-dns-sd-10 == Outdated reference: A later version (-14) exists of draft-ietf-core-link-format-06 == Outdated reference: A later version (-04) exists of draft-shelby-core-coap-req-02 == Outdated reference: A later version (-05) exists of draft-shelby-core-resource-directory-00 Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CoRE K. Lynn 3 Internet-Draft Consultant 4 Intended status: Standards Track Z. Shelby 5 Expires: January 5, 2012 Sensinode 6 July 04, 2011 8 CoRE Link-Format to DNS-Based Service Discovery Mapping 9 draft-lynn-core-discovery-mapping-00 11 Abstract 13 Resource and service discovery are complimentary. Resource discovery 14 provides fine-grained detail about the content of a server, while 15 service discovery can provide a scable method to locate servers in 16 large networks. This document defines a method for mapping between 17 CoRE Link-Format attributes and DNS-Based Service Discovery fields so 18 the two methods can be jointly employed in large scale networks. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on January 5, 2012. 37 Copyright Notice 39 Copyright (c) 2011 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Mapping CoRE Link Attributes to DNS-SD Records . . . . . . . . 5 56 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 57 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 58 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 59 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7 60 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 61 7.1. Normative References . . . . . . . . . . . . . . . . . . . 8 62 7.2. Informative References . . . . . . . . . . . . . . . . . . 8 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 65 1. Introduction 67 The Constrained RESTful Environments (CoRE) working group aims at 68 realizing the REST architecture in a suitable form for the most 69 constrained nodes (e.g. 8-bit microcontrollers with limited RAM and 70 ROM) and networks (e.g. 6LoWPAN). CoRE is aimed at machine-to- 71 machine (M2M) applications such as smart energy and building 72 automation. 74 Automated discovery of resources hosted by a constrained server is 75 critical in machine-to-machine applications where human intervention 76 is minimal and static interfaces result in fragility. CoRE Resource 77 Discovery is intended to support fine-grained discovery of hosted 78 resources, their attributes, and other resource relations 79 [I-D.ietf-core-link-format]. 81 In contrast, service discovery generally refers to a coarse-grained 82 resolution of a service access point's IP address, port number, and 83 protocol. Resource and service discovery are complimentary in the 84 case of large networks, where the latter can facilitate scaling. 85 This document defines a mapping between CoRE Resource Discovery and 86 DNS-Based Service Discovery [I-D.cheshire-dnsext-dns-sd] fields that 87 permits discovery of CoAP servers by either means. It also satisfies 88 a literal interpretation of the following CoRE charter requirement 89 [I-D.shelby-core-coap-req]: 91 REQ8: A definition of how to use CoAP to advertise about or query 92 for a Device's description. This description may include the 93 device name and a list of its Resources, each with a URL, an 94 interface description URI (pointing e.g. to a Web Application 95 Description Language (WADL) document) and an optional name or 96 identifier. The name taxonomy used for this description will 97 be consistent with other IETF work, e.g. 98 draft-cheshire-dnsext-dns-sd. [charter] 100 1.1. Terminology 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 104 document are to be interpreted as described in "Key words for use in 105 RFCs to Indicate Requirement Levels" [RFC2119]. 107 1.2. DNS-Based Service Discovery 109 DNS-Based Service Discovery (DNS-SD) defines a conventional way to 110 configure DNS PTR, SRV, and TXT records to facilitate discovery of 111 services (such as CoAP nodes within a subdomain) using the existing 112 DNS infrastructure. This section gives a cursory overview of DNS-SD; 113 see [I-D.cheshire-dnsext-dns-sd] for a detailed specification. 115 DNS-SD service names are of the form Instance.ServiceType.Location, 116 where the default ServiceType for CoAP nodes is "_coap._udp". (The 117 identifier "_udp" is required for DNS-SD SRV record definitions and 118 "_coap" identifies the application protocol.) For each CoAP end- 119 point in the domain, a PTR record with the name _coap._udp is defined 120 and each PTR value references SRV and TXT records having the 121 Instance.ServiceType.Location name. 123 DNS-SD currently supports one level of subtype, which MAY be used to 124 locate coap services based on object model, for example: 125 _bacnet._sub._coap._udp, _dali._sub._coap._udp, or 126 _zigbee._sub._coap._udp. The maximum length of each type and subtype 127 fields is 15 octets including the underscore. It is proposed to 128 eliminate the "_sub" string and allow any number of _subtype strings, 129 subject to the overall 255 octet limit on service names. 131 The Location part of the service name is identical to the DNS 132 (sub)domain part of the authority in URIs that identify the resources 133 on this node or group and may, for example, identify a building zone. 135 The Instance part of the service name is defined as part of the 136 commissioning process. It must be unique within the (sub)domain. 137 The complete service name uniquely identifies both a SRV and TXT 138 record in the DNS zone. The granularity of a service name MAY be 139 that of a host or group, or it could represent a particular resource 140 within a coap node. The SRV record contains the host (AAAA record) 141 name and port of the service. In the case where a service name 142 identifies a particular resource, the path part of the URI must be 143 placed in the TXT record. 145 1.3. Resource Discovery 147 While service discovery is concerned with finding the IP address, 148 port, and protocol of a named service, resource discovery is a fine- 149 grained discovery of resource URIs within a web service. 150 [I-D.ietf-core-link-format] specifies a resource discovery pattern, 151 such that sending a confirmable GET message for the /.well-known/core 152 resource returns a set of links that identify all resources present 153 on this node that are exposed as functions. 155 1.4. Resource Directory 157 A Resource Directory (RD) is used as a repository for Web Links 158 [RFC5988] about resources hosted on other web servers, which are 159 called end-points (EP). An end-point is a web server associated with 160 a port, thus a physical node may host one or more end-points. The RD 161 implements a set of REST interfaces for end-points to register and 162 maintain sets of Web Links (called resource directory entries), for 163 the RD to validate entries, and for clients to lookup resources from 164 the RD. End-points themselves can also act as clients. 166 2. Mapping CoRE Link Attributes to DNS-SD Records 168 ---------+---------+---------+---------+---------+---------+--------- 169 [Discuss here the new RD attributes] 171 link-extension = ( "ins" "=" quoted-string ) ; Max 63 octets 172 link-extension = ( "exp" ) 174 Resource Instance (ins=) is mapped to DNS-SD Service Instance (as 175 defined in core-resource-directory) 176 Resource Type (rt=) is mapped to the DNS-SD service type and subtypes 177 is mapped to the DNS-SD TXT record PATH= 178 Interface Description (if=) is mapped to the DNS-SD TXT record IF= 180 The following CoRE specific target attributes as defined in 181 [I-D.ietf-core-link-format] are imported directly into DNS-SD if 182 "exp" is present. The values are intended to be imported directly 183 into a DNS-SD zone file are are subject to format and length 184 constraints as specified in [I-D.cheshire-dnsext-dns-sd]. 186 2.1. Resource Instance "ins" attribute 188 The Resource Instance "ins" attribute is the Instance portion of a 189 DNS-SD service name. It is stored directly in the DNS as a single 190 DNS label of canonical precomposed UTF-8 [RFC3629] "Net-Unicode" 191 (Unicode Normalization Form C) [RFC5198] text. However, to the 192 extent that the "ins" attribute may be chosen to match the DNS host 193 name of a proxy or gateway, it SHOULD use the syntax defined in 194 Section 3.5 of [RFC1034] and Section 2.1 of [RFC1123]. 196 The Instance portion of the name of a service being offered on the 197 network SHOULD be configurable by the user setting up the service, so 198 that he or she may give it an informative name. However, the device 199 or service SHOULD NOT require the user to configure a name before it 200 can be used. A sensible choice of default name can allow the device 201 or service to be accessed in many cases without any manual 202 configuration at all. The default name should be short and 203 descriptive, and MAY include the device's MAC address, serial number, 204 or any similar hexadecimal string in an attempt to make the name 205 globally unique. 207 DNS labels are currently limited to 63 octets in length and the 208 entire service name may not exceed 255 octets. 210 2.2. Resource Type "rt" attribute 212 The resource type "rt" attribute is mapped into the ServiceType 213 portion of a DNS-SD instance name and must conform to the following 214 format. It must be comprised of Net-Unicode text stings, each 215 preceded by an underscore '_' and limited to 15 octets in length. 216 The strings must be separated by periods '.' and prepended to the 217 default CoAP ServiceType "_coap._udp". The resulting string is used 218 to form labels for DNS-SD records and as such is stored directly in 219 the DNS. 221 [TBD: If the default type is always "_coap._udp" do we need to 222 specify it? If not, do we need separate attributes for type and 223 subtype strings?] 225 2.3. Location 227 [ A method must be specified to determine in which DNS zone the CoAP 228 service should be registered in. Perhaps some way to map subnet into 229 DNS subdomain name.] 231 3. Examples 233 Assuming the ability to access a Resource Directory, or multicast a 234 GET over the local link, CoAP resource discovery can be used to 235 populate the DNS-SD database in an automated fashion. CoAP resource 236 descriptions can be imported into DNS-SD for exposure to service 237 discovery by using the "ins" attribute as the basis for a unique 238 "Instance" name, defaulting to "_coap._udp" for the ServiceType, and 239 using some means to establish which domain the service should be 240 registered in [TBD]. The DNS TXT record can be populated by 241 importing the other resource description attributes as they share the 242 same key=value format specified in Section 6 of 243 [I-D.cheshire-dnsext-dns-sd]. 245 Examples [TBD] 247 4. IANA Considerations 249 This document makes no request of IANA. 251 Note to RFC Editor: this section may be removed on publication as an 252 RFC. 254 5. Security Considerations 256 [TBD] 258 6. Acknowledgments 260 Contributions and review comments were made by Anders Brandt, Angelo 261 Castellani, and Peter van der Stok. 263 7. References 265 7.1. Normative References 267 [RFC0020] Cerf, V., "ASCII format for network interchange", RFC 20, 268 October 1969. 270 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 271 STD 13, RFC 1034, November 1987. 273 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 274 and Support", STD 3, RFC 1123, October 1989. 276 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 277 Requirement Levels", BCP 14, RFC 2119, March 1997. 279 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 280 specifying the location of services (DNS SRV)", RFC 2782, 281 February 2000. 283 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 284 10646", STD 63, RFC 3629, November 2003. 286 [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network 287 Interchange", RFC 5198, March 2008. 289 [RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010. 291 7.2. Informative References 293 [I-D.cheshire-dnsext-dns-sd] 294 Cheshire, S. and M. Krochmal, "DNS-Based Service 295 Discovery", draft-cheshire-dnsext-dns-sd-10 (work in 296 progress), February 2011. 298 [I-D.ietf-core-link-format] 299 Shelby, Z., "CoRE Link Format", 300 draft-ietf-core-link-format-06 (work in progress), 301 June 2011. 303 [I-D.shelby-core-coap-req] 304 Shelby, Z., Stuber, M., Sturek, D., Frank, B., and R. 305 Kelsey, "CoAP Requirements and Features", 306 draft-shelby-core-coap-req-02 (work in progress), 307 October 2010. 309 [I-D.shelby-core-resource-directory] 310 Shelby, Z. and S. Krco, "CoRE Resource Directory", 311 draft-shelby-core-resource-directory-00 (work in 312 progress), June 2011. 314 Authors' Addresses 316 Kerry Lynn 317 Consultant 319 Phone: +1 978 460 4253 320 Email: kerlyn@ieee.org 322 Zach Shelby 323 Sensinode 324 Kidekuja 2 325 Vuokatti 88600 326 FINLAND 328 Phone: +358407796297 329 Email: zach@sensinode.com