draft-ietf-core-senml-etch-06.txt   draft-ietf-core-senml-etch-07.txt 
Network Working Group A. Keranen Network Working Group A. Keranen
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Standards Track M. Mohajer Intended status: Standards Track M. Mohajer
Expires: June 29, 2020 u-blox UK Expires: September 10, 2020 March 9, 2020
December 27, 2019
FETCH & PATCH with Sensor Measurement Lists (SenML) FETCH & PATCH with Sensor Measurement Lists (SenML)
draft-ietf-core-senml-etch-06 draft-ietf-core-senml-etch-07
Abstract Abstract
The Sensor Measurement Lists (SenML) media type and data model can be The Sensor Measurement Lists (SenML) media type and data model can be
used to send collections of resources, such as batches of sensor data used to send collections of resources, such as batches of sensor data
or configuration parameters. The CoAP FETCH, PATCH, and iPATCH or configuration parameters. The CoAP FETCH, PATCH, and iPATCH
methods enable accessing and updating parts of a resource or multiple methods enable accessing and updating parts of a resource or multiple
resources with one request. This document defines new media types resources with one request. This document defines new media types
for the CoAP FETCH, PATCH, and iPATCH methods for resources for the CoAP FETCH, PATCH, and iPATCH methods for resources
represented with the SenML data model. represented with the SenML data model.
skipping to change at page 1, line 37 skipping to change at page 1, line 36
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 29, 2020. This Internet-Draft will expire on September 10, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Using FETCH and (i)PATCH with SenML . . . . . . . . . . . . . 3 3. Using FETCH and (i)PATCH with SenML . . . . . . . . . . . . . 3
3.1. SenML FETCH . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. SenML FETCH . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. SenML (i)PATCH . . . . . . . . . . . . . . . . . . . . . 5 3.2. SenML (i)PATCH . . . . . . . . . . . . . . . . . . . . . 5
4. Fragment Identification . . . . . . . . . . . . . . . . . . . 6 4. Fragment Identification . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 5. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6.1. CoAP Content-Format Registration . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
6.2. senml-etch+json Media Type . . . . . . . . . . . . . . . 7 7.1. CoAP Content-Format Registration . . . . . . . . . . . . 8
6.3. senml-etch+cbor Media Type . . . . . . . . . . . . . . . 8 7.2. senml-etch+json Media Type . . . . . . . . . . . . . . . 8
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 7.3. senml-etch+cbor Media Type . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . 10 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . 10 9.1. Normative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 9.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
The Sensor Measurement Lists (SenML) media type [RFC8428] and data The Sensor Measurement Lists (SenML) media type [RFC8428] and data
model can be used to transmit collections of resources, such as model can be used to transmit collections of resources, such as
batches of sensor data or configuration parameters. batches of sensor data or configuration parameters.
An example of a SenML collection is shown below: An example of a SenML collection is shown below:
[ [
skipping to change at page 3, line 9 skipping to change at page 3, line 9
are "2001:db8::2/3311/0/5850", etc. are "2001:db8::2/3311/0/5850", etc.
The CoAP [RFC7252] FETCH, PATCH, and iPATCH methods [RFC8132] enable The CoAP [RFC7252] FETCH, PATCH, and iPATCH methods [RFC8132] enable
accessing and updating parts of a resource or multiple resources with accessing and updating parts of a resource or multiple resources with
one request. one request.
This document defines two new media types, one using the JavaScript This document defines two new media types, one using the JavaScript
Object Notation (JSON) [RFC8259] and one using the Concise Binary Object Notation (JSON) [RFC8259] and one using the Concise Binary
Object Representation (CBOR) [RFC7049], which can be used with the Object Representation (CBOR) [RFC7049], which can be used with the
CoAP FETCH, PATCH, and iPATCH methods for resources represented with CoAP FETCH, PATCH, and iPATCH methods for resources represented with
the SenML data model. The rest of the document uses term "(i)PATCH" the SenML data model (i.e., for both SenML and Sensor Streaming
when referring to both methods as the semantics of the new media Measurement Lists (SenSML) data). The rest of the document uses term
types are the same for the CoAP PATCH and iPATCH methods. "(i)PATCH" when referring to both methods as the semantics of the new
media types are the same for the CoAP PATCH and iPATCH methods.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
Readers should also be familiar with the terms and concepts discussed Readers should also be familiar with the terms and concepts discussed
skipping to change at page 4, line 47 skipping to change at page 4, line 49
The SenML time and unit fields can be used in a Fetch Record to The SenML time and unit fields can be used in a Fetch Record to
further narrow the selection of matched SenML Records. When no time further narrow the selection of matched SenML Records. When no time
or unit is given in a Fetch Record, all SenML Records with the given or unit is given in a Fetch Record, all SenML Records with the given
name are matched (i.e., unlike with SenML Records, lack of time field name are matched (i.e., unlike with SenML Records, lack of time field
in a Fetch Record does not imply time value zero). When time is in a Fetch Record does not imply time value zero). When time is
given in the Fetch Record, only the SenML Records (if any) with equal given in the Fetch Record, only the SenML Records (if any) with equal
resolved time value and name are matched. Similarly, when unit is resolved time value and name are matched. Similarly, when unit is
given, only the SenML Records with equal resolved unit and name are given, only the SenML Records with equal resolved unit and name are
matched. If both time and unit are given in the Fetch Record, both matched. If both time and unit are given in the Fetch Record, both
MUST to match for the SenML Record to match. MUST to match for the SenML Record to match. Each Target Record MUST
be included in the response at most once, even if multiple Fetch
Records match with the same Target Record.
For example, if the IPSO resource "5850" would have multiple sensor For example, if the IPSO resource "5850" would have multiple sensor
readings (SenML Records) with different time values, the following readings (SenML Records) with different time values, the following
Fetch Pack can be used to retrieve the Record with time Fetch Pack can be used to retrieve the Record with time
"1.276020091e+09": "1.276020091e+09":
[ [
{"bn":"2001:db8::2/3311/0/", "n":"5850", "t":1.276020091e+09} {"bn":"2001:db8::2/3311/0/", "n":"5850", "t":1.276020091e+09}
] ]
The resolved form of records (Section 4.6 of [RFC8428]) is used when The resolved form of records (Section 4.6 of [RFC8428]) is used when
comparing the names, times, and units of the Target and Fetch Records comparing the names, times, and units of the Target and Fetch Records
to accommodate for differences in use of the base values. In to accommodate for differences in use of the base values. In
resolved form the SenML name in the example above becomes resolved form the SenML name in the example above becomes
"2001:db8::2/3311/0/5850". Since there is no base time in the Pack, "2001:db8::2/3311/0/5850". Since there is no base time in the Pack,
the time in resolved form is equal to the time in the example. the time in resolved form is equal to the time in the example.
If no SenML Records match, empty SenML Pack (i.e., array with no If no SenML Records match, empty SenML Pack (i.e., array with no
elements) is returned as a response. elements) is returned as a response.
All other Fetch Record fields than name, base name, time, base time, Fetch Records MUST NOT contain other fields than name, base name,
unit, and base unit MUST be ignored. time, base time, unit, and base unit. Implementations MUST reject
and generate an error for a Fetch Pack with other fields. [RFC8132]
Section 2.2 provides guidance for FETCH request error handling, e.g.,
using the 4.22 (Unprocessable Entity) CoAP error response code.
3.2. SenML (i)PATCH 3.2. SenML (i)PATCH
The (i)PATCH method can be used to change the fields of SenML The (i)PATCH method can be used to change the fields of SenML
Records, to add new Records, and to remove existing Records. The Records, to add new Records, and to remove existing Records. The
names, times, and units of the Patch Records are given and matched in names, times, and units of the Patch Records are given and matched in
same way as for the Fetch Records, except each Patch Record MUST same way as for the Fetch Records, except each Patch Record MUST
match at most one Target Record. Patch Packs can also include new match at most one Target Record. A Patch Record matching more than
values and other SenML fields for the Records. Application of Patch one Target Record is considered invalid (patching multiple Target
Packs is idempotent; hence PATCH and iPATCH methods for SenML Packs Records with one Patch Record would result in multiple copies of the
are equivalent. same record). Patch Packs can also include new values and other
SenML fields for the Records. Application of Patch Packs is
idempotent; hence PATCH and iPATCH methods for SenML Packs are
equivalent.
When the name in a Patch Record matches with the name in an existing When the name in a Patch Record matches with the name in an existing
Record, the resolved time values and units (if any) are compared. If Record, the resolved time values and units (if any) are compared. If
the time values and units either do not exist in both Records or are the time values and units either do not exist in both Records or are
equal, the Target Record is replaced with the contents of the Patch equal, the Target Record is replaced with the contents of the Patch
Record. All Patch Records MUST contain at least a SenML Value or Sum Record. All Patch Records MUST contain at least a SenML Value or Sum
field. A Patch Pack with invalid Records MUST be rejected. field.
If a Patch Record contains a name, or combination of a time value, If a Patch Record contains a name, or combination of a time value,
unit, and a name, that do not exist in any existing Record in the unit, and a name, that do not exist in any existing Record in the
Pack, the given Record, with all the fields it contains, is added to Pack, the given Record, with all the fields it contains, is added to
the Pack. the Pack.
If a Patch Record has a value ("v") field with value null, it MUST If a Patch Record has a value ("v") field with value null, it MUST
NOT be added but the matched Record (if any) is removed from the NOT be added but the matched Record (if any) is removed from the
Target Pack. Target Pack.
The Patch Records MUST be applied in the same sequence they are in
the Patch Pack. If multiple Patch Packs are being processed at the
same time, the result MUST be equivalent to applying them in one
sequence.
Implementations MUST reject and generate an error for Patch Packs
with invalid Records. If a Patch Pack is rejected, the state of the
Target Pack is not changed, i.e., either all or none of the Patch
Records are applied. [RFC8132] Section 3.4 provides guidance for
error handling with PATCH and iPATCH requests, e.g., using the 4.22
(Unprocessable Entity) and 4.09 (Conflict) CoAP error response codes.
For example, the following document could be given as an (i)PATCH For example, the following document could be given as an (i)PATCH
payload to change/set values of two SenML Records for the example in payload to change/set values of two SenML Records for the example in
Section 1: Section 1:
[ [
{"bn":"2001:db8::2/3311/0/", "n":"5850", "vb":false}, {"bn":"2001:db8::2/3311/0/", "n":"5850", "vb":false},
{"n":"5851", "v":10} {"n":"5851", "v":10}
] ]
If the request is successful, the resulting representation of the If the request is successful, the resulting representation of the
skipping to change at page 6, line 37 skipping to change at page 7, line 15
4. Fragment Identification 4. Fragment Identification
Fragment identification for Records of Fetch and Patch Packs uses the Fragment identification for Records of Fetch and Patch Packs uses the
same mechanism as SenML JSON/CBOR fragment identification (see same mechanism as SenML JSON/CBOR fragment identification (see
Section 9 of [RFC8428]), i.e., "rec" scheme followed by a comma- Section 9 of [RFC8428]), i.e., "rec" scheme followed by a comma-
separated list of Record positions or range(s) of Records. For separated list of Record positions or range(s) of Records. For
example, to select the 3rd and 5th Record of a Fetch or Patch Pack, a example, to select the 3rd and 5th Record of a Fetch or Patch Pack, a
fragment identifier "rec=3,5" can be used in the URI of the Fetch or fragment identifier "rec=3,5" can be used in the URI of the Fetch or
Patch Pack resource. Patch Pack resource.
5. Security Considerations 5. Extensibility
The SenML mandatory to understand fields extensibility mechanism (see
section 4.4 in [RFC8428]) does not apply to Patch Packs, i.e.,
unknown fields MUST NOT generate an error but such fields are treated
like any other field (e.g., added to Patch target records where
applicable).
This specification allows only a small subset of SenML fields in
Fetch Records but future specifications may enable new fields for
Fetch Records and possibly also new fields for selecting targets for
Patch Records.
6. Security Considerations
The security and privacy considerations of SenML apply also with the The security and privacy considerations of SenML apply also with the
FETCH and (i)PATCH methods. CoAP's security mechanisms are used to FETCH and (i)PATCH methods. CoAP's security mechanisms are used to
provide security for the FETCH and (i)PATCH methods. provide security for the FETCH and (i)PATCH methods.
In FETCH and (i)PATCH requests, the client can pass arbitrary names In FETCH and (i)PATCH requests, the client can pass arbitrary names
to the target resource for manipulation. The resource implementer to the target resource for manipulation. The resource implementer
must take care to only allow access to names that are actually part must take care to only allow access to names that are actually part
of (or accessible through) the target resource. of (or accessible through) the target resource. In particular the
receiver needs to ensure that any input does not lead to uncontrolled
special interpretation by the system.
If the client is not allowed to do a GET or PUT on the full target If the client is not allowed to do a GET or PUT on the full target
resource (and thus all the names accessible through it), access resource (and thus all the names accessible through it), access
control rules must be evaluated for each record in the pack. control rules must be evaluated for each record in the pack.
6. IANA Considerations 7. IANA Considerations
This document registers two new media types and CoAP Content-Format This document registers two new media types and CoAP Content-Format
IDs for both media types. IDs for both media types.
Note to RFC Editor: Please replace all occurrences of "RFC-AAAA" with Note to RFC Editor: Please replace all occurrences of "RFC-AAAA" with
the RFC number of this document. the RFC number of this document.
6.1. CoAP Content-Format Registration 7.1. CoAP Content-Format Registration
IANA is requested to assign CoAP Content-Format IDs for the SenML IANA is requested to assign CoAP Content-Format IDs for the SenML
PATCH and FETCH media types in the "CoAP Content-Formats" sub- PATCH and FETCH media types in the "CoAP Content-Formats" sub-
registry, within the "CoRE Parameters" registry [RFC7252]. The registry, within the "CoRE Parameters" registry [RFC7252]. The
assigned IDs are shown in Table 1. assigned IDs are shown in Table 1.
+-----------------------------+----------+---------+ +-----------------------------+----------+---------+
| Media type | Encoding | ID | | Media type | Encoding | ID |
+-----------------------------+----------+---------+ +-----------------------------+----------+---------+
| application/senml-etch+json | - | TBD-320 | | application/senml-etch+json | - | TBD-320 |
| | | | | | | |
| application/senml-etch+cbor | - | TBD-322 | | application/senml-etch+cbor | - | TBD-322 |
+-----------------------------+----------+---------+ +-----------------------------+----------+---------+
Table 1: CoAP Content-Format IDs Table 1: CoAP Content-Format IDs
6.2. senml-etch+json Media Type 7.2. senml-etch+json Media Type
Type name: application Type name: application
Subtype name: senml-etch+json Subtype name: senml-etch+json
Required parameters: N/A Required parameters: N/A
Optional parameters: N/A Optional parameters: N/A
Encoding considerations: binary Encoding considerations: binary
Security considerations: See Section 5 of RFC-AAAA. Security considerations: See Section 6 of RFC-AAAA.
Interoperability considerations: Applications MUST ignore any key Interoperability considerations: N/A
value pairs that they do not understand unless the key ends with the
'_' character in which case an error MUST be generated. This allows
backwards compatible extensions to this specification.
Published specification: RFC-AAAA Published specification: RFC-AAAA
Applications that use this media type: Applications that use the Applications that use this media type: Applications that use the
SenML media type for resource representation. SenML media type for resource representation.
Fragment identifier considerations: Fragment identification for Fragment identifier considerations: Fragment identification for
application/senml-etch+json is supported by using fragment application/senml-etch+json is supported by using fragment
identifiers as specified by RFC AAAA. identifiers as specified by RFC AAAA.
skipping to change at page 8, line 35 skipping to change at page 9, line 24
Keranen ari.keranen@ericsson.com Keranen ari.keranen@ericsson.com
Intended usage: COMMON Intended usage: COMMON
Restrictions on usage: N/A Restrictions on usage: N/A
Author: Ari Keranen ari.keranen@ericsson.com Author: Ari Keranen ari.keranen@ericsson.com
Change controller: IESG Change controller: IESG
6.3. senml-etch+cbor Media Type 7.3. senml-etch+cbor Media Type
Type name: application Type name: application
Subtype name: senml-etch+cbor Subtype name: senml-etch+cbor
Required parameters: N/A Required parameters: N/A
Optional parameters: N/A Optional parameters: N/A
Encoding considerations: binary Encoding considerations: binary
Security considerations: See Section 5 of RFC-AAAA. Security considerations: See Section 6 of RFC-AAAA.
Interoperability considerations: Applications MUST ignore any key Interoperability considerations: N/A
value pairs that they do not understand unless the key ends with the
'_' character in which case an error MUST be generated. This allows
backwards compatible extensions to this specification.
Published specification: RFC-AAAA Published specification: RFC-AAAA
Applications that use this media type: Applications that use the Applications that use this media type: Applications that use the
SenML media type for resource representation. SenML media type for resource representation.
Fragment identifier considerations: Fragment identification for Fragment identifier considerations: Fragment identification for
application/senml-etch+cbor is supported by using fragment application/senml-etch+cbor is supported by using fragment
identifiers as specified by RFC AAAA. identifiers as specified by RFC AAAA.
skipping to change at page 9, line 38 skipping to change at page 10, line 24
Keranen ari.keranen@ericsson.com Keranen ari.keranen@ericsson.com
Intended usage: COMMON Intended usage: COMMON
Restrictions on usage: N/A Restrictions on usage: N/A
Author: Ari Keranen ari.keranen@ericsson.com Author: Ari Keranen ari.keranen@ericsson.com
Change controller: IESG Change controller: IESG
7. Acknowledgements 8. Acknowledgements
The use of FETCH and (i)PATCH methods with SenML was first introduced The use of FETCH and (i)PATCH methods with SenML was first introduced
by the OMA SpecWorks LwM2M v1.1 specification. This document by the OMA SpecWorks LwM2M v1.1 specification. This document
generalizes the use to any SenML representation. The authors would generalizes the use to any SenML representation. The authors would
like to thank Carsten Bormann, Christian Amsuess, Jaime Jimenez, like to thank Carsten Bormann, Christian Amsuess, Jaime Jimenez,
Klaus Hartke, Michael Richardson, and other participants from the Klaus Hartke, Michael Richardson, and other participants from the
IETF CoRE and OMA SpecWorks DMSE working groups who have contributed IETF CoRE and OMA SpecWorks DMSE working groups who have contributed
ideas and reviews. ideas and reviews.
8. References 9. References
8.1. Normative References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
October 2013, <https://www.rfc-editor.org/info/rfc7049>. October 2013, <https://www.rfc-editor.org/info/rfc7049>.
skipping to change at page 10, line 39 skipping to change at page 11, line 24
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259, Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017, DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/info/rfc8259>. <https://www.rfc-editor.org/info/rfc8259>.
[RFC8428] Jennings, C., Shelby, Z., Arkko, J., Keranen, A., and C. [RFC8428] Jennings, C., Shelby, Z., Arkko, J., Keranen, A., and C.
Bormann, "Sensor Measurement Lists (SenML)", RFC 8428, Bormann, "Sensor Measurement Lists (SenML)", RFC 8428,
DOI 10.17487/RFC8428, August 2018, DOI 10.17487/RFC8428, August 2018,
<https://www.rfc-editor.org/info/rfc8428>. <https://www.rfc-editor.org/info/rfc8428>.
8.2. Informative References 9.2. Informative References
[IPSO] IPSO, "IPSO Light Control Smart Object", 2018, [IPSO] IPSO, "IPSO Light Control Smart Object", 2018,
<http://www.openmobilealliance.org/tech/profiles/ <http://www.openmobilealliance.org/tech/profiles/
lwm2m/3311.xml>. lwm2m/3311.xml>.
Authors' Addresses Authors' Addresses
Ari Keranen Ari Keranen
Ericsson Ericsson
skipping to change at page 11, line 4 skipping to change at page 11, line 36
[IPSO] IPSO, "IPSO Light Control Smart Object", 2018, [IPSO] IPSO, "IPSO Light Control Smart Object", 2018,
<http://www.openmobilealliance.org/tech/profiles/ <http://www.openmobilealliance.org/tech/profiles/
lwm2m/3311.xml>. lwm2m/3311.xml>.
Authors' Addresses Authors' Addresses
Ari Keranen Ari Keranen
Ericsson Ericsson
Email: ari.keranen@ericsson.com Email: ari.keranen@ericsson.com
Mojan Mohajer Mojan Mohajer
u-blox UK
Email: Mojan.Mohajer@u-blox.com Email: mojanm@hotmail.com
 End of changes. 27 change blocks. 
48 lines changed or deleted 79 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/