idnits 2.17.1 draft-rahman-core-advanced-rd-features-02.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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 18, 2016) is 2951 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC7390' is defined on line 219, but no explicit reference was found in the text == Outdated reference: A later version (-28) exists of draft-ietf-core-resource-directory-05 == Outdated reference: A later version (-11) exists of draft-silverajan-core-coap-alternative-transports-09 -- Obsolete informational reference (is this intentional?): RFC 7230 (Obsoleted by RFC 9110, RFC 9112) Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CORE WG A. Rahman 3 Internet-Draft C. Wang 4 Intended status: Informational InterDigital Communications, LLC 5 Expires: September 19, 2016 March 18, 2016 7 Advanced Resource Directory Features 8 draft-rahman-core-advanced-rd-features-02 10 Abstract 12 The Resource Directory (RD) is a key element for successful 13 deployments of constrained networks. Similar to the HTTP web search 14 engines (e.g. Google, Bing), the RD for CoAP should also support 15 useful search query responses beyond a basic listing of relevant 16 links. This document proposes several new features to be considered 17 for the RD. The only goal of this document is to trigger discussion 18 in the CoRE WG so that all relevant features for RD evolution are 19 taken into account during CoRE re-charter activities. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on September 19, 2016. 38 Copyright Notice 40 Copyright (c) 2016 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Terminology and Conventions . . . . . . . . . . . . . . . . . 2 56 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 2 57 3. Proposal . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 60 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 61 7. Security Considerations . . . . . . . . . . . . . . . . . . . 4 62 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 8.1. Normative References . . . . . . . . . . . . . . . . . . 4 64 8.2. Informative References . . . . . . . . . . . . . . . . . 5 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 67 1. Terminology and Conventions 69 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 70 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 71 document are to be interpreted as described in RFC 2119 [RFC2119]. 73 This document assumes readers are familiar with the terms and 74 concepts that are used in [RFC6690], [RFC7252] and 75 [I-D.ietf-core-resource-directory]. 77 2. Background 79 The concept of the Resource Directory (RD) is described in 80 [I-D.ietf-core-resource-directory]. It is defined as a node which 81 hosts descriptions of resources held on other servers, allowing 82 lookups to be performed for those resources. The 83 [I-D.ietf-core-resource-directory] specifies the web interfaces that 84 a Resource Directory supports in order for devices to discover the RD 85 and to register, maintain, lookup and remove resources descriptions. 87 The relevant specification of interfaces in 88 [I-D.ietf-core-resource-directory] is given using the CoAP protocol 89 [RFC7252] for all interfaces. Also, HTTP protocol [RFC7230] support 90 is given for some interfaces. For example, all the response 91 codes(i.e. success and error) for registering and looking up 92 resources support both CoAP and HTTP. However, the important 93 multicast discovery interface does not support HTTP. The Group 94 interface also does not support HTTP. 96 The CoRE Link Format [RFC6690] describes the format of the payload of 97 a CoAP message that carries a set of CoAP URIs. With relation to the 98 RD, the CoRE Link Format is be used by a device to carry (encode) the 99 set of URIs it wants to register with an RD. Also, the CoRE Link 100 Format is used to carry (encode) the set of URIs returned by a RD for 101 a lookup query (including the initial multicast discovery request). 102 While in theory the CoRE Link Format [RFC6690] specification states 103 that it may be used with HTTP, in practice many details still need to 104 be fleshed out and specified before this can be realized. 106 3. Proposal 108 It is proposed that the RD should also support the following 109 additional features: 111 1. Explicit HTTP Support - Though there is some support of HTTP in 112 [I-D.ietf-core-resource-directory], the specification should be 113 further expanded to also explicitly support HTTP for the Discovery 114 and perhaps the Group Functions. Also, the RD function is intimately 115 tied to the CoRE Link Format [RFC6690] which does not have any 116 explicit support of HTTP at all. So the CoRE Link Format definitely 117 needs to be updated to support HTTP explicitly. 119 2. Mirror Server - The CoRE WG has previously discussed the concept 120 of a mirror server in relation to supporting sleepy devices. 121 Specifically, [I-D.vial-core-mirror-server] recommends to create a 122 new class of RDs which store the actual resource representations (as 123 opposed to simply storing the URI) in a special type of RD called the 124 Mirror Server. Communicating devices can both lookup the resource, 125 and then also fetch directly the resource representation, from the 126 Mirror Server regardless of the state of the sleepy server. 128 3. Re-direction to another RD - A given RD may not have the URIs 129 being queried for registered in its database. The given RD should 130 have the capability to re-direct the querying client to another RD 131 which may have the information of interest. 133 4. URI Ranking - Current Internet search engines (e.g. Google) have 134 extensive methods for ranking the URIs returned to a human initiated 135 search query. For example, the concept of Search Engine Optimization 136 (SEO) has spawned a large industry in the web world for specifically 137 this purpose. The concept of URI ranking (to indicate the "value" of 138 the URI) should also be supported by the RD. 140 5. Indication of transport protocol - Several proposals exist(e.g. 141 [I-D.silverajan-core-coap-alternative-transports]) in the CoRE WG to 142 support alternative transports (e.g. TCP, SMS) for CoAP beyond the 143 current UDP transport. It would be very useful if search results 144 from a RD indicated the type of transport supported by a given URI. 146 6. Privacy Model - IoT devices may often contain sensitive 147 information (e.g. health monitoring device) or affect human safety 148 (e.g. traffic light controllers, elevator actuators). When the 149 resources of a device is registered with a given RD and domain, 150 should anyone at all be able to easily discover the resources 151 associated with the device? Does this cause privacy or security 152 concerns in certain RD lookup scenarios? Currently, 153 [I-D.ietf-core-resource-directory] has a very brief mention that 154 endpoint and clients should be authenticated and access controlled. 155 However, a more complete privacy model should be developed to address 156 this very important issue. 158 4. Summary 160 The proposed set of feature extensions for the RD will improve the 161 constrained environment search capability and make deployments more 162 efficient. These RD feature extensions should be individually 163 considered during the CoRE re-charter discussions. Evolution and 164 forward thinking is required for the CoRE RD, as constantly occurs in 165 the current Internet for HTTP web search engines (e.g. Google). 167 5. Acknowledgements 169 TBD. 171 6. IANA Considerations 173 This memo includes no request to IANA. 175 7. Security Considerations 177 Not applicable. 179 8. References 181 8.1. Normative References 183 [I-D.ietf-core-resource-directory] 184 Shelby, Z., Koster, M., Bormann, C., and P. Stok, "CoRE 185 Resource Directory", draft-ietf-core-resource-directory-05 186 (work in progress), October 2015. 188 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 189 Requirement Levels", BCP 14, RFC 2119, 190 DOI 10.17487/RFC2119, March 1997, 191 . 193 8.2. Informative References 195 [I-D.silverajan-core-coap-alternative-transports] 196 Silverajan, B. and T. Savolainen, "CoAP Communication with 197 Alternative Transports", draft-silverajan-core-coap- 198 alternative-transports-09 (work in progress), December 199 2015. 201 [I-D.vial-core-mirror-server] 202 Vial, M., "CoRE Mirror Server", draft-vial-core-mirror- 203 server-01 (work in progress), April 2013. 205 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 206 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 207 . 209 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 210 Protocol (HTTP/1.1): Message Syntax and Routing", 211 RFC 7230, DOI 10.17487/RFC7230, June 2014, 212 . 214 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 215 Application Protocol (CoAP)", RFC 7252, 216 DOI 10.17487/RFC7252, June 2014, 217 . 219 [RFC7390] Rahman, A., Ed. and E. Dijk, Ed., "Group Communication for 220 the Constrained Application Protocol (CoAP)", RFC 7390, 221 DOI 10.17487/RFC7390, October 2014, 222 . 224 Authors' Addresses 226 Akbar Rahman 227 InterDigital Communications, LLC 229 Email: akbar.rahman@interdigital.com 231 Chonggang Wang 232 InterDigital Communications, LLC 234 Email: chonggang.wang@interdigital.com