idnits 2.17.1 draft-liu-t2trg-ps-smart-home-vocabulary-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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 30, 2016) is 2706 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Liu 3 Internet-Draft Q. An 4 Intended status: Experimental Alibaba Group 5 Expires: May 3, 2017 October 30, 2016 7 Problem Statement for Smart Home Device Vocabulary 8 draft-liu-t2trg-ps-smart-home-vocabulary-00 10 Abstract 12 This document provides an overview of the issues associated with the 13 IoT device information model of smart home applications and systems. 15 Requirements Language 17 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 18 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 19 document are to be interpreted as described in RFC 2119 [RFC2119]. 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 May 3, 2017. 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 2 57 2.1. Device Information Model Vocabulary Fragmentation . . . . 3 58 2.2. Standardization of Information Model . . . . . . . . . . 3 59 3. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . 4 60 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 61 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 62 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 63 7. Normative References . . . . . . . . . . . . . . . . . . . . 4 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 4 66 1. Introduction 68 Smart home is one of vertical applications of Internet of Things 69 (IoT). The deployment of smart home applications and systems often 70 requires various types of devices (for example, home appliances) from 71 different device manufacturers, and each device requires multiple 72 properties and/or methods (for example, switch, mode, etc.) 73 supported. 75 Now, many consortiums are working on device models to descibe the 76 properties and methods of IoT devices, like information model to 77 describe the data produced by device, and interaction model to define 78 how to interact with device. However, simply relying on device model 79 still cannot guarantee the semantic interoperability. 81 Current device information model vocabularies for smart home are 82 often tightly coupled to limited number of device manufacturers, thus 83 resulting in relatively rigid and static device vocabularies. The 84 static nature of such device vocabularies greatly reduces and, in 85 many cases, limits the ability of a smart home service provider to 86 introduce new or modify existing device properties and/or methods. 88 This document outlines the problems encountered with existing device 89 information model vocabularies for smart home, and provides the 90 requirement that is necessary to solve the problem. 92 2. Problem Statement 94 The following points describe aspects of existing smart home device 95 vocabularies that are problematic. 97 2.1. Device Information Model Vocabulary Fragmentation 99 Device information model vocabularies are often coupled to specific 100 device manufacturers. Even for same kind of device type, the 101 information model's properties and command are different. For 102 example, for the air conditioner, manufacturer A may define its 103 switch feature as "on", and define value 1 as "switch on" and value 0 104 as "switch off"; whereas, manufacturer B may define the switch 105 feature as "open", and define value 1 as "switch on" and value 0 as 106 "switch off". 108 Such Fragmentation imposes constraints on smart home deployment, 109 potentially inhibiting the smart home service provider from providing 110 smart device interaction function for customers, and reduces 111 flexibility because it would be difficult to support devices from new 112 manufacturers. 114 One possible solution is to define an unified information model 115 specification. Each device manufacturer can map its private device 116 information model, thus helping to bridge between different device 117 information model. This information model could be implemented on 118 the IoT service platform in the cloud or locally on the smart home 119 appliacne. If implemented on Intrnet server, it is easy for device 120 manufacturers to configure the mapping, but it may bring extra cost 121 to IoT service platform as well as increase its complexity. If 122 implemented locally, it could bring better user experience since the 123 briding is completed locally, but the updating of device information 124 model would be difficult. 126 2.2. Standardization of Information Model 128 Even though many consortiums are working on defining an universal 129 device information model for smart home, there is still no dominant 130 standard that can cover the requirements of most manufacturers. 132 ZigBee Alliance is working on "ZigBee Cluster Library", which defines 133 the device model as well as the detailed device vocabulary for smart 134 home. But it is only limited to ZigBee environment. 136 OCF is working on "Smart Home Device Specification", which defines 137 the device model and vocabulary for smart home. But the vocabulary 138 is very basic, thus cannot satisfy the requirement of samrt home 139 implementation. 141 W3C is also woring on TD (Things Description) standards. 143 However, those information model related standards only trying to 144 standardize the way of describing the IoT device's property and its 145 command. The difficulty is that there is no common "vocabulary" for 146 the information model of the IoT device. Although the information 147 model could be standardized, it is still impossible to interoperate 148 in this case. 150 3. Proposed Solution 152 Define an unified "vocabulary" standards for the information model of 153 smart home. This standards could be crucial to enable interoperate 154 for smart home appliance. 156 4. IANA Considerations 158 TBD 160 5. Security Considerations 162 TBD 164 6. Acknowledgements 166 TBD 168 7. Normative References 170 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 171 Requirement Levels", BCP 14, RFC 2119, 172 DOI 10.17487/RFC2119, March 1997, 173 . 175 Authors' Addresses 177 Dapeng Liu 178 Alibaba Group 179 Beijing 180 Beijing 182 Phone: +86-1391788933 183 Email: maxpassion@gmail.com 185 Qing An 186 Alibaba Group 187 Beijing 188 Beijing 190 Phone: +86-13810495624 191 Email: anqing.aq@alibaba-inc.com