[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

CORE WG                                                        A. Rahman
Internet-Draft                                                   C. Wang
Intended status: Informational          InterDigital Communications, LLC
Expires: September 19, 2016                               March 18, 2016


                  Advanced Resource Directory Features
               draft-rahman-core-advanced-rd-features-02

Abstract

   The Resource Directory (RD) is a key element for successful
   deployments of constrained networks.  Similar to the HTTP web search
   engines (e.g.  Google, Bing), the RD for CoAP should also support
   useful search query responses beyond a basic listing of relevant
   links.  This document proposes several new features to be considered
   for the RD.  The only goal of this document is to trigger discussion
   in the CoRE WG so that all relevant features for RD evolution are
   taken into account during CoRE re-charter activities.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on September 19, 2016.

Copyright Notice

   Copyright (c) 2016 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must



Rahman & Wang          Expires September 19, 2016               [Page 1]


Internet-Draft    Advanced Resource Directory Features        March 2016


   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Terminology and Conventions . . . . . . . . . . . . . . . . .   2
   2.  Background  . . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  Proposal  . . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Summary . . . . . . . . . . . . . . . . . . . . . . . . . . .   4
   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   4
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   4
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   4
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   5
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   5

1.  Terminology and Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

   This document assumes readers are familiar with the terms and
   concepts that are used in [RFC6690], [RFC7252] and
   [I-D.ietf-core-resource-directory].

2.  Background

   The concept of the Resource Directory (RD) is described in
   [I-D.ietf-core-resource-directory].  It is defined as a node which
   hosts descriptions of resources held on other servers, allowing
   lookups to be performed for those resources.  The
   [I-D.ietf-core-resource-directory] specifies the web interfaces that
   a Resource Directory supports in order for devices to discover the RD
   and to register, maintain, lookup and remove resources descriptions.

   The relevant specification of interfaces in
   [I-D.ietf-core-resource-directory] is given using the CoAP protocol
   [RFC7252] for all interfaces.  Also, HTTP protocol [RFC7230] support
   is given for some interfaces.  For example, all the response
   codes(i.e. success and error) for registering and looking up
   resources support both CoAP and HTTP.  However, the important
   multicast discovery interface does not support HTTP.  The Group
   interface also does not support HTTP.





Rahman & Wang          Expires September 19, 2016               [Page 2]


Internet-Draft    Advanced Resource Directory Features        March 2016


   The CoRE Link Format [RFC6690] describes the format of the payload of
   a CoAP message that carries a set of CoAP URIs.  With relation to the
   RD, the CoRE Link Format is be used by a device to carry (encode) the
   set of URIs it wants to register with an RD.  Also, the CoRE Link
   Format is used to carry (encode) the set of URIs returned by a RD for
   a lookup query (including the initial multicast discovery request).
   While in theory the CoRE Link Format [RFC6690] specification states
   that it may be used with HTTP, in practice many details still need to
   be fleshed out and specified before this can be realized.

3.  Proposal

   It is proposed that the RD should also support the following
   additional features:

   1.  Explicit HTTP Support - Though there is some support of HTTP in
   [I-D.ietf-core-resource-directory], the specification should be
   further expanded to also explicitly support HTTP for the Discovery
   and perhaps the Group Functions.  Also, the RD function is intimately
   tied to the CoRE Link Format [RFC6690] which does not have any
   explicit support of HTTP at all.  So the CoRE Link Format definitely
   needs to be updated to support HTTP explicitly.

   2.  Mirror Server - The CoRE WG has previously discussed the concept
   of a mirror server in relation to supporting sleepy devices.
   Specifically, [I-D.vial-core-mirror-server] recommends to create a
   new class of RDs which store the actual resource representations (as
   opposed to simply storing the URI) in a special type of RD called the
   Mirror Server.  Communicating devices can both lookup the resource,
   and then also fetch directly the resource representation, from the
   Mirror Server regardless of the state of the sleepy server.

   3.  Re-direction to another RD - A given RD may not have the URIs
   being queried for registered in its database.  The given RD should
   have the capability to re-direct the querying client to another RD
   which may have the information of interest.

   4.  URI Ranking - Current Internet search engines (e.g.  Google) have
   extensive methods for ranking the URIs returned to a human initiated
   search query.  For example, the concept of Search Engine Optimization
   (SEO) has spawned a large industry in the web world for specifically
   this purpose.  The concept of URI ranking (to indicate the "value" of
   the URI) should also be supported by the RD.

   5.  Indication of transport protocol - Several proposals exist(e.g.
   [I-D.silverajan-core-coap-alternative-transports]) in the CoRE WG to
   support alternative transports (e.g.  TCP, SMS) for CoAP beyond the




Rahman & Wang          Expires September 19, 2016               [Page 3]


Internet-Draft    Advanced Resource Directory Features        March 2016


   current UDP transport.  It would be very useful if search results
   from a RD indicated the type of transport supported by a given URI.

   6.  Privacy Model - IoT devices may often contain sensitive
   information (e.g. health monitoring device) or affect human safety
   (e.g. traffic light controllers, elevator actuators).  When the
   resources of a device is registered with a given RD and domain,
   should anyone at all be able to easily discover the resources
   associated with the device?  Does this cause privacy or security
   concerns in certain RD lookup scenarios?  Currently,
   [I-D.ietf-core-resource-directory] has a very brief mention that
   endpoint and clients should be authenticated and access controlled.
   However, a more complete privacy model should be developed to address
   this very important issue.

4.  Summary

   The proposed set of feature extensions for the RD will improve the
   constrained environment search capability and make deployments more
   efficient.  These RD feature extensions should be individually
   considered during the CoRE re-charter discussions.  Evolution and
   forward thinking is required for the CoRE RD, as constantly occurs in
   the current Internet for HTTP web search engines (e.g.  Google).

5.  Acknowledgements

   TBD.

6.  IANA Considerations

   This memo includes no request to IANA.

7.  Security Considerations

   Not applicable.

8.  References

8.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-05
              (work in progress), October 2015.







Rahman & Wang          Expires September 19, 2016               [Page 4]


Internet-Draft    Advanced Resource Directory Features        March 2016


   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

8.2.  Informative References

   [I-D.silverajan-core-coap-alternative-transports]
              Silverajan, B. and T. Savolainen, "CoAP Communication with
              Alternative Transports", draft-silverajan-core-coap-
              alternative-transports-09 (work in progress), December
              2015.

   [I-D.vial-core-mirror-server]
              Vial, M., "CoRE Mirror Server", draft-vial-core-mirror-
              server-01 (work in progress), April 2013.

   [RFC6690]  Shelby, Z., "Constrained RESTful Environments (CoRE) Link
              Format", RFC 6690, DOI 10.17487/RFC6690, August 2012,
              <http://www.rfc-editor.org/info/rfc6690>.

   [RFC7230]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
              Protocol (HTTP/1.1): Message Syntax and Routing",
              RFC 7230, DOI 10.17487/RFC7230, June 2014,
              <http://www.rfc-editor.org/info/rfc7230>.

   [RFC7252]  Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
              Application Protocol (CoAP)", RFC 7252,
              DOI 10.17487/RFC7252, June 2014,
              <http://www.rfc-editor.org/info/rfc7252>.

   [RFC7390]  Rahman, A., Ed. and E. Dijk, Ed., "Group Communication for
              the Constrained Application Protocol (CoAP)", RFC 7390,
              DOI 10.17487/RFC7390, October 2014,
              <http://www.rfc-editor.org/info/rfc7390>.

Authors' Addresses

   Akbar Rahman
   InterDigital Communications, LLC

   Email: akbar.rahman@interdigital.com


   Chonggang Wang
   InterDigital Communications, LLC

   Email: chonggang.wang@interdigital.com



Rahman & Wang          Expires September 19, 2016               [Page 5]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/