idnits 2.17.1 draft-tschofenig-core-senml-lbn-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 : ---------------------------------------------------------------------------- ** There are 5 instances of too long lines in the document, the longest one being 5 characters in excess of 72. -- The draft header indicates that this document updates RFC8428, but the abstract doesn't seem to mention this, which it should. 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 (June 18, 2019) is 1745 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) No issues found here. Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CORE H. Tschofenig 3 Internet-Draft Arm Ltd. 4 Updates: 8428 (if approved) June 18, 2019 5 Intended status: Standards Track 6 Expires: December 20, 2019 8 Introducing the Local Base Name in SenML 9 draft-tschofenig-core-senml-lbn-00 11 Abstract 13 The Sensor Measurement Lists (SenML) specification defines a format 14 for representing simple sensor measurements and device parameters. 15 This specification defines a new label to relax the requirement for 16 global identification of every measurement. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on December 20, 2019. 35 Copyright Notice 37 Copyright (c) 2019 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3. Local Base Name SenML Structure and Semantics . . . . . . . . 4 55 4. CDDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 57 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 58 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 59 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 8.1. Normative References . . . . . . . . . . . . . . . . . . 5 61 8.2. Informative References . . . . . . . . . . . . . . . . . 5 62 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 64 1. Introduction 66 The Sensor Measurement Lists (SenML) specification, see RFC 8428 67 [RFC8428], defines a format for representing simple sensor 68 measurements and device parameters. 70 Ideally, sensor readings used in the Internet of Things environment 71 should be as small as possible. For this reason the specification 72 also defines an encoding of these sensor measurements and device 73 parameters in CBOR (on top of other serialization formats). 75 A design decision in SenML was, however, that each measurement 76 transmitted over the network is self-contained and contains 77 information that uniquely identifies and differentiates the sensor 78 from all others - not only locally on the device but globally. 80 This is accomplished by the combination of two fields, namely the 81 'Name' and the 'Base Name' values. The specification requires the 82 concatenation of the Name and the Base Name values to yield the name 83 of the sensor and recommends that the concatenated names be 84 represented as URIs or URNs. 86 Figure 1 is an example taken from RFC 8428. 88 [ 89 {"bn":"urn:dev:ow:10e2073a01080063:","n":"temp","u":"Cel","v":23.1}, 90 {"n":"label","vs":"Machine Room"}, 91 {"n":"open","vb":false}, 92 {"n":"nfc-reader","vd":"aGkgCg"} 93 ] 95 Figure 1: SenML Example Measurement with Base Name value 97 The global identification of every measurement as it is traveling 98 through the network and through different systems has its use case 99 and allows easy identification of the source and enables correlation. 101 Unfortunately, it also has drawbacks: 103 o The unique identification of the sensor adds a substantial 104 overhead, particularly when the sensor identification is verbose. 105 Deployed systems, for example, make use of RFC 4122 [RFC4122] Type 106 5 Universally Unique IDentifier (UUIDs). 108 o The global identification of every measurements is often 109 unnecessary when the SenML is used as a mechanism to represent 110 data for device-to-clould communication or cloud-to-gateway 111 communication where data is subsequently processed, aggregated or 112 otherwise modified. In such systems, the identification of the 113 sensor and the device has its origin in the security context 114 rather than in the SenML contained measurment. LwM2M [LWM2M] is 115 an example of such an architecture. 117 o Finally, there are privacy implications of globally identifying 118 each measurements and some deployments may prefer better privacy 119 protection over ease of correlation. 121 This specification therefore updates RFC 8428 and defines a new Local 122 Base Name value (lbn) that can be used instead of the Base Name value 123 defined in RFC 8428. 125 Figure 2 shows an example based on LwM2M use of SenML. 127 [ 128 {"lbn":"/3303/", "n":"0/5700/", "v":25.2}, 129 {"n":"/1/5700/", "v":5} 130 ] 132 Figure 2: SenML Example Measurement with Local Base Name value 134 Note: In the LwM2M data model objects, object instances, and 135 resources are encoded as numerical values. The value of '3303' 136 refers to the Temperature object, '0' and '1' to the two instances of 137 the resource '5700' (Sensor Value). Hence, this measurement 138 indicates that the two temperator sensors expose their sensor 139 readings. 141 2. Terminology 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 145 "OPTIONAL" in this document are to be interpreted as described in BCP 146 14 [RFC2119] [RFC8174] when, and only when, they appear in all 147 capitals, as shown here. 149 3. Local Base Name SenML Structure and Semantics 151 This specification defines one new lable, the Local Base Name value, 152 which is used instead of the Base Name value. For practical purposes 153 the Local Base Name / Name concatination does not need to be a URN or 154 a URI because existing data models used in the IoT space do not all 155 make use of URIs/URNs. 157 +-------------------+-------+------------+------------+------------+ 158 | Name | Label | CBOR Label | JSON Type | XML Type | 159 +-------------------+-------+------------+------------+------------+ 160 | Local Base Name | lbn | 8 | String | string | 161 +-------------------+-------+------------+------------+------------+ 163 Figure 3: Local Base Name SenML Label 165 4. CDDL 167 This document defines a new value to be added to the CDDL defined in 168 Section 11 of RFC 8428. 170 The new key-value-pair is 172 lbn => tstr ; Local Base Name 174 5. Security Considerations 176 This document inherits the security properties of RFC 8428 but 177 improves its privacy features by removing the unique identification 178 of the sensor when the Local Base Name value is used instead of the 179 Name / Base Name combination. 181 6. IANA Considerations 183 IANA is asked to register the following new entry in the SenML Labels 184 Registry. 186 +-----------------+-------+----+-----------+----------+----+--------------+ 187 | Name | Label | CL | JSON Type | XML Type | EI | Reference | 188 +-----------------+-------+----+-----------+----------+----+--------------+ 189 | Local Base Name | lbn | 8 | String | string | a |[[This RFC]] | 190 +-----------------+-------+----+-----------+----------+----+--------------+ 192 Note that CL = CBOR Label and EI = EXI ID. 194 7. Acknowledgements 196 The author would like to thank the OMA Device Management and Service 197 Enablement working group for their discussion and their input. In 198 particular, I would to thank Ari Keranen, David Navarro, Mojan 199 Mohajer and Alan Soloway. 201 8. References 203 8.1. Normative References 205 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 206 Requirement Levels", BCP 14, RFC 2119, March 1997. 208 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 209 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 210 May 2017, . 212 [RFC8428] Jennings, C., Shelby, Z., Arkko, J., Keranen, A., and C. 213 Bormann, "Sensor Measurement Lists (SenML)", RFC 8428, DOI 214 10.17487/RFC8428, August 2018, . 217 8.2. Informative References 219 [LWM2M] Open Mobile Alliance, "Lightweight Machine to Machine 220 Technical Specification Version 1.0", February 2017, 221 . 225 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 226 Unique IDentifier (UUID) URN Namespace", RFC 4122, DOI 227 10.17487/RFC4122, July 2005, . 230 Author's Address 232 Hannes Tschofenig 233 Arm Ltd. 234 110 Fulbourn Rd 235 Cambridge CB1 9NJ 236 UK 238 Email: Hannes.tschofenig@arm.com 239 URI: http://www.tschofenig.priv.at