idnits 2.17.1 draft-keranen-core-senml-base-prefix-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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 22, 2019) is 1738 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) == Outdated reference: A later version (-28) exists of draft-ietf-core-resource-directory-23 -- Obsolete informational reference (is this intentional?): RFC 7230 (Obsoleted by RFC 9110, RFC 9112) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Keranen 3 Internet-Draft Ericsson 4 Intended status: Standards Track C. Amsuess 5 Expires: January 23, 2020 July 22, 2019 7 SenML Base Name Prefix Indication 8 draft-keranen-core-senml-base-prefix-00 10 Abstract 12 The Sensor Measurement Lists (SenML) media type uses globally unique 13 names to facilitate information exchange across systems. This 14 requirement often leads to long names and hence large amount of data 15 to be transmitted with each SenML Pack. This document defines an 16 efficient mechanism to indicate a globally unique prefix for names. 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 https://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 January 23, 2020. 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 (https://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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Indicating base name prefix . . . . . . . . . . . . . . . . . 3 55 3.1. IP address . . . . . . . . . . . . . . . . . . . . . . . 4 56 3.2. Request Base URI . . . . . . . . . . . . . . . . . . . . 4 57 3.3. Public key fingerprint . . . . . . . . . . . . . . . . . 4 58 3.4. TLS PSK Identity . . . . . . . . . . . . . . . . . . . . 5 59 3.5. CoRE Resource Directory endpoint ID . . . . . . . . . . . 5 60 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 61 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 6 62 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 6.1. Normative References . . . . . . . . . . . . . . . . . . 6 64 6.2. Informative References . . . . . . . . . . . . . . . . . 7 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 67 1. Introduction 69 The Sensor Measurement Lists (SenML) media type [RFC8428] indicates 70 sources of information with globally unique names. A SenML Pack can 71 indicate "base names" ("bn" field) that are prefixed to all names 72 ("n" fields) in the SenML Records where the "bn" appears and all 73 subsequent records until a new base name is indicated. Example of a 74 SenML Pack with two sources of measurement data that share a base 75 name is shown in Figure 1. 77 [ 78 {"bn":"2001:db8:1234:5678::1/", 79 "n":"temperature", "u":"Cel", "v":25.2}, 80 {"n":"humidity", "u":"%RH", "v":30} 81 ] 83 Figure 1: SenML Pack with two sources of measurements 85 The base name construct enables indicating the globally unique part 86 of the name only once for a set of Records. However, the globally 87 unique part still needs to be indicated in each Pack. Since base 88 name is often relatively long, in some scenarios it would be useful 89 to be able to further compress or omit this information. 91 Since the sender and receiver of a SenML Pack often share context 92 information beyond what is in the SenML Pack, e.g., request URI when 93 a RESTful protocol is used, sender IP address, or security 94 association information. This information can be used to assist 95 constructing the globally unique part of a name. However, the sender 96 of the Pack needs to be able to indicate unambiguously what 97 information is used and how the name is generated from that 98 information. 100 This document registers a new SenML field to indicate what 101 information outside of the SenML Pack should be used as a prefix to 102 the base name(s). Also rules for consistently creating SenML names 103 from this information is specified for each information source. 105 Since SenML has only a small set of characters that are allowed in 106 names (see Section 4.5.1 in [RFC8428]) replacing rules for characters 107 outside of this set (e.g., brackets and semicolons) are also defined. 109 2. Terminology 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 113 "OPTIONAL" in this document are to be interpreted as described in 114 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 115 capitals, as shown here. 117 Readers should also be familiar with the terms and concepts discussed 118 in [RFC8428]. 120 3. Indicating base name prefix 122 SenML field "bpi" contains an integer value that indicates what 123 information should be used by the receiver to construct a prefix to 124 the base names. This document defines following modes: 126 1: IPv4 or IPv6 address of the sender 128 2: IPv4 or IPv6 address and port of the sender 130 3: Base URI of the request URI 132 5: Fingerprint of the public key of the sender 134 6: TLS PSK Identity 136 10: CoRE Resource Directory endpoint ID 138 The following sub-sections define rules for generating SenML basename 139 prefix for each mode. Some rules require replacing characters from 140 the input identifiers with characters that are safe for SenML names. 141 Applying these rules may result in multiple different input 142 identifiers being mapped to the same output identifer. The sender of 143 the SenML Pack MUST ensure that such mapping does not result in 144 conflicting names from that sender. 146 3.1. IP address 148 The SenML Pack sender IP address can be used without (mode 1) or with 149 (mode 2) port number to generate the base name prefix. 151 For IPv6 addresses the format defined in [RFC5952] without brackets 152 ("[" and "]") MUST be used. 154 Example: "2001:db8::1" 156 For IPv6 address and port underscore ("_") for port separator MUST be 157 used. 159 Example: "2001:db8::1_5683" 161 For IPv4 addresses the "dot decimal" notation MUST be used. 163 Example: "192.0.2.1" 165 For IPv4 addresses colon (":") MUST be used for port separator. 167 Example: "192.0.2.1:5684" 169 3.2. Request Base URI 171 When a RESTful protocol (e.g., CoAP [RFC7252] or HTTP [RFC7230]) is 172 used to request a SenML Pack, the base of the target request URI can 173 be used as the base name prefix. If IP address is used in the 174 authority part of the URI, rules in Section 3.1 MUST be followed for 175 it. 177 Characters in the URI that are not in the character set allowed for 178 SenML names MUST be replaced with the underscore ("_") character. 180 Example: "coap://example.com/room1/" 182 3.3. Public key fingerprint 184 When X.509 certificate or raw public key is used to setup the 185 security association (e.g., a TLS connection) to retrieve a SenML 186 Pack, a fingerprint of the public key of the sender of the SenML Pack 187 can be used as the base name prefix. For a public key fingerprint 188 the "URL Segment Format" of [RFC6920] with ";" characters replaced 189 with "_" MUST be used. 191 Example: "sha-256_UyaQV-Ev4rdLoHyJJWCi11OHfrYv9E1aGQAlMO2X_-Q" 193 3.4. TLS PSK Identity 195 When a pre-shared key (PSK) ciphersuites (e.g., [RFC4279])) are used 196 to establish a TLS connection, the PSK identity can be used as the 197 base name prefix. In this mode the PSK identity from the TLS 198 handshake with characters not allowed for SenML names replaced with 199 "_" MUST be used. 201 Example: "foo.example.com" 203 3.5. CoRE Resource Directory endpoint ID 205 When the sender has registered with the receiving system using the 206 CoRE Resource Directory [I-D.ietf-core-resource-directory] interface, 207 and has defined an "endpoint name" during the registration, the 208 endpoint name can be used as the base name prefix. Characters not 209 allowed for SenML names MUST be replaced with "_". 211 Example: "urn:dev:ow:10e2073a01080063" 213 4. IANA Considerations 215 IANA is requested to assign a new label in the "SenML Labels" 216 subregistry of the SenML registry [IANA.senml] (as defined in 217 [RFC8428]) for the "Base Name Prefix Indicator" as follows: 219 +-----------------------+-------+----------+---------+--------------+ 220 | Name | Label | JSON | XML | Reference | 221 | | | Type | Type | | 222 +-----------------------+-------+----------+---------+--------------+ 223 | Base Name Prefix | bpi | Number | int | this | 224 | Indicator | | | | document | 225 +-----------------------+-------+----------+---------+--------------+ 227 IANA is requested to create a new "SenML Base Name Prefix Indicator 228 modes" subregistry to the SenML registry. Initial contents of the 229 subregistry is shown below: 231 +-------------------+-------+---------------+ 232 | Name | Value | Reference | 233 +-------------------+-------+---------------+ 234 | IP address | 1 | this document | 235 | | | | 236 | IP address & port | 2 | this document | 237 | | | | 238 | Base URI | 3 | this document | 239 | | | | 240 | Public key | 5 | this document | 241 | | | | 242 | TLS PSK ID | 6 | this document | 243 | | | | 244 | CoRE RD endpoint | 10 | this document | 245 +-------------------+-------+---------------+ 247 Acknowledgements 249 TBD 251 6. References 253 6.1. Normative References 255 [I-D.ietf-core-resource-directory] 256 Shelby, Z., Koster, M., Bormann, C., Stok, P., and C. 257 Amsuess, "CoRE Resource Directory", draft-ietf-core- 258 resource-directory-23 (work in progress), July 2019. 260 [IANA.senml] 261 IANA, "Sensor Measurement Lists (SenML)", 262 . 264 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 265 Requirement Levels", BCP 14, RFC 2119, 266 DOI 10.17487/RFC2119, March 1997, 267 . 269 [RFC4279] Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key 270 Ciphersuites for Transport Layer Security (TLS)", 271 RFC 4279, DOI 10.17487/RFC4279, December 2005, 272 . 274 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 275 Address Text Representation", RFC 5952, 276 DOI 10.17487/RFC5952, August 2010, 277 . 279 [RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., 280 Keranen, A., and P. Hallam-Baker, "Naming Things with 281 Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013, 282 . 284 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 285 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 286 May 2017, . 288 [RFC8428] Jennings, C., Shelby, Z., Arkko, J., Keranen, A., and C. 289 Bormann, "Sensor Measurement Lists (SenML)", RFC 8428, 290 DOI 10.17487/RFC8428, August 2018, 291 . 293 6.2. Informative References 295 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 296 Protocol (HTTP/1.1): Message Syntax and Routing", 297 RFC 7230, DOI 10.17487/RFC7230, June 2014, 298 . 300 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 301 Application Protocol (CoAP)", RFC 7252, 302 DOI 10.17487/RFC7252, June 2014, 303 . 305 Authors' Addresses 307 Ari Keranen 308 Ericsson 309 Jorvas 02420 310 Finland 312 Email: ari.keranen@ericsson.com 314 Christian Amsuess 315 Hollandstr. 12/4 316 1020 317 Austria 319 Phone: +43-664-9790639 320 Email: christian@amsuess.com