draft-ietf-lmap-restconf-00.txt   draft-ietf-lmap-restconf-01.txt 
Network Working Group J. Schoenwaelder Network Working Group J. Schoenwaelder
Internet-Draft V. Bajpai Internet-Draft V. Bajpai
Intended status: Standards Track Jacobs University Bremen Intended status: Standards Track Jacobs University Bremen
Expires: January 4, 2016 July 3, 2015 Expires: May 4, 2016 November 1, 2015
Using RESTCONF with LMAP Measurement Agents Using RESTCONF with LMAP Measurement Agents
draft-ietf-lmap-restconf-00.txt draft-ietf-lmap-restconf-01.txt
Abstract Abstract
This document describes how RESTCONF can be used with a YANG data This document describes how RESTCONF can be used with a YANG data
model for Large-Scale Measurement Platforms (LMAP). model for Large-Scale Measurement Platforms (LMAP).
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
skipping to change at page 1, line 31 skipping to change at page 1, line 31
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 January 4, 2016. This Internet-Draft will expire on May 4, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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. Overview of RESTCONF . . . . . . . . . . . . . . . . . . . . 2 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2
2. Overview of RESTCONF . . . . . . . . . . . . . . . . . . . . 3
3. RESTCONF as LMAP Control Protocol . . . . . . . . . . . . . . 3 3. RESTCONF as LMAP Control Protocol . . . . . . . . . . . . . . 3
4. RESTCONF as LMAP Report Protocol . . . . . . . . . . . . . . 3 4. RESTCONF as LMAP Report Protocol . . . . . . . . . . . . . . 3
5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4
8. Informative References . . . . . . . . . . . . . . . . . . . 4 8. Informative References . . . . . . . . . . . . . . . . . . . 4
Appendix A. Response to Protocol Comparison Criteria . . . . . . 5 Appendix A. Example RESTCONF Control Protocol Exchange . . . . . 5
Appendix B. Example RESTCONF Control Protocol Exchange . . . . . 7 Appendix B. Example RESTCONF Report Protocol Exchange . . . . . 7
Appendix C. Example RESTCONF Report Protocol Exchange . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
This document discusses how a controller can use the RESTCONF This document discusses how a Controller can use the RESTCONF
protocol [I-D.ietf-netconf-restconf] to configure Large-Scale protocol [I-D.ietf-netconf-restconf] to configure Large-Scale
Measurement of Broadband Performance (LMAP) measurement agents (MAs) Measurement of Broadband Performance (LMAP) Measurement Agents
[I-D.ietf-lmap-framework]. It also discusses how RESTCONF can be [RFC7594]. It also discusses how RESTCONF can be used by a
used to report measurement results to a collector. Measurement Agent to report measurement results to a Collector.
MAs may be deployed as separate hardware devices or as functions Measurement Agents may be deployed as separate hardware devices or as
embedded in consumer electronic devices and home routers or as pure functions embedded in consumer electronic devices and home routers or
software solutions that can be installed on off-the-shelf computing as pure software solutions that can be installed on off-the-shelf
equipment. Measurement agents receive instructions from a controller computing equipment. Measurement Agents receive instructions from a
about when and how to conduct what measurements (the measurement Controller about when and how to conduct what measurements (the
schedule) and how and when to report measurement results to a data measurement schedule) and how and when to report measurement results
collector (the report schedule). Further information about the to a data Collector (the report schedule). Further information about
interaction between MAs and controllers and collectors can be found the interaction between Measurement Agents and Controllers and
in [I-D.ietf-lmap-framework]. Collectors can be found in [RFC7594].
The LMAP information model [I-D.ietf-lmap-information-model] defines The LMAP information model [I-D.ietf-lmap-information-model] defines
the information exchanged between a controller and an MA and the the information exchanged between a Controller and an Measurement
information exchanged between an MA and a collector. An information Agent and the information exchanged between an Measurement Agent and
model is conceptual and protocol-independent. A concrete YANG a Collector. An information model is conceptual and protocol-
[RFC6020] data model derived from the conceptual information model is independent. A concrete YANG [RFC6020] data model derived from the
defined in [I-D.ietf-lmap-yang]. conceptual information model is defined in [I-D.ietf-lmap-yang].
1.1. Terminology
This document uses the LMAP terminology defined in [RFC7594].
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 [RFC2119].
2. Overview of RESTCONF 2. Overview of RESTCONF
The RESTCONF protocol [I-D.ietf-netconf-restconf] provides a REST- The RESTCONF protocol [I-D.ietf-netconf-restconf] provides a REST-
like interface to access and manipulate a so-called unified YANG like interface to access and manipulate a so-called unified YANG
datastore [RFC6020]. The basic idea behind RESTCONF is expose a YANG datastore [RFC6020]. The basic idea behind RESTCONF is expose a YANG
datastores as a collection of Web resources that can be manipulated datastores as a collection of Web resources that can be manipulated
using standard HTTP [RFC7230] DELETE, PATCH, POST, and PUT methods. using standard HTTP [RFC7230] DELETE, PATCH, POST, and PUT methods.
The resource hierarchy is derived from the nesting structure of the The resource hierarchy is derived from the nesting structure of the
YANG schema tree, leading to a so called data model driven REST API. YANG schema tree, leading to a so-called data model driven REST API.
RESTCONF is essentially a convention how to use HTTP over TLS to RESTCONF is essentially a convention how to use HTTP over TLS to
access a datastore that has a structure defined by a YANG data model. access a datastore that has a structure defined by a YANG data model.
The data is exchanged in XML encoding or JSON encoding. The data is exchanged in XML encoding or JSON encoding.
The normal mode of operation is that the RESTCONF client initiates a The normal mode of operation is that the RESTCONF client initiates a
secure transport to the RESTCONF server. For devices located behind secure transport to the RESTCONF server. For devices located behind
a NAT, a so called 'call-home' mechanism has been defined a NAT, a so called 'call-home' mechanism has been defined
[I-D.ietf-netconf-call-home] that enables the RESTCONF server to [I-D.ietf-netconf-call-home] that enables the RESTCONF server to
establish a secure transport to a RESTCONF client. Note that call establish a secure transport to a RESTCONF client. Note that call
home only changes the TCP connection establishment, the TLS and HTTP home only changes the TCP connection establishment, the TLS and HTTP
client/server roles do not change. The policy used to call home can client/server roles do not change. The policy used to call home can
be configured through a configuration data model be configured through a configuration data model
[I-D.ietf-netconf-server-model]. This model provides mechanism to [I-D.ietf-netconf-server-model]. This model provides a mechanism to
configure a list of redundant endpoints and it provides control over configure a list of redundant endpoints and it provides control over
call-home policies (e.g, call-home frequency, idle-timers, keep-alive call-home policies (e.g, call-home frequency, idle-timers, keep-alive
timers). timers).
3. RESTCONF as LMAP Control Protocol 3. RESTCONF as LMAP Control Protocol
It is straight-forward to user RESTCONF as a control protocol. The It is straight-forward to use RESTCONF as a control protocol. The
YANG data model [I-D.ietf-lmap-yang] derived from the underlying YANG data model [I-D.ietf-lmap-yang] derived from the underlying
information model [I-D.ietf-lmap-information-model] translates into a information model [I-D.ietf-lmap-information-model] translates into a
collection of RESTCONF resources that can be manipulated at various collection of RESTCONF resources that can be manipulated at various
levels of granularity using DELETE, PATCH, POST, and PUT methods. levels of granularity using DELETE, PATCH, POST, and PUT methods.
An example exchange showing a REST call to create a schedule object An example exchange showing a REST call to create a schedule object
is shown in Appendix B. is shown in Appendix A.
4. RESTCONF as LMAP Report Protocol 4. RESTCONF as LMAP Report Protocol
One way of mapping the information model parts relevant for reports For reporting results from the Measurement Agent to a Collector, the
into a YANG data model is the usage of YANG notifications. This is Collector is assumed to act as a RESTCONF server. The Measurement
the approach currently used in [I-D.ietf-lmap-yang]. This mapping Agent pushes results to the Collector by invoking an operation on the
leads to report notifications that push measurement results from the Controller.
MA to a collector. The RESTCONF protocol uses Server Sent Events as
the underlying mechanism to stream notifications.
A direct mapping of the information model leads to relatively verbose
exchanges and it is possible to define more space efficient
notifications that suppress information that is only changing rarely.
An example exchange of a result notification is shown in Appendix C.
Note that alternative designs are possible. One option is to make
the collector a RESTCONF server and to have the MA push results to
the collector by posting to resources on the controller. Another
option is to have the results reside on the MA and to export the
results as part of the operational state of the MA. The collector(s)
will then use GET requests to fetch the result resources from the MA.
Note that all three approaches can be implemented using RESTCONF and
YANG.
5. Conclusion 5. Security Considerations
This document discusses how RESTCONF can be used as a control TBD
protocol and a report protocol for Large-Scale Measurement Platforms
(LMAP). The benefit of using RESTCONF is that no new protocol work
needs to be done. Additional benefits derive from using YANG and a
data model driven approach. Despite the reuse of existing tools,
using a data model driven approach allows to easily reuse other data
models (e.g., network interfaces [RFC7223], [RFC7277] or general
system services [RFC7317]) in order to export additional status
information about an MA to a controller.
6. IANA Considerations 6. IANA Considerations
This document has no requests for IANA. This document has no requests for IANA.
7. Acknowledgements 7. Acknowledgements
Juergen Schoenwaelder and Vaibhav Bajpai work in part on the Leone Juergen Schoenwaelder and Vaibhav Bajpai worked in part on the Leone
research project, which receives funding from the European Union research project, which received funding from the European Union
Seventh Framework Programme [FP7/2007-2013] under grant agreement Seventh Framework Programme [FP7/2007-2013] under grant agreement
number 317647. number 317647.
8. Informative References Juergen Schoenwaelder and Vaibhav Bajpai were partly funded by
Flamingo, a Network of Excellence project (ICT-318488) supported by
the European Commission under its Seventh Framework Programme.
[I-D.ietf-lmap-framework] 8. Informative References
Eardley, P., Morton, A., Bagnulo, M., Burbridge, T.,
Aitken, P., and A. Akhter, "A framework for Large-Scale
Measurement of Broadband Performance (LMAP)", draft-ietf-
lmap-framework-12 (work in progress), March 2015.
[I-D.ietf-lmap-information-model] [I-D.ietf-lmap-information-model]
Burbridge, T., Eardley, P., Bagnulo, M., and J. Burbridge, T., Eardley, P., Bagnulo, M., and J.
Schoenwaelder, "Information Model for Large-Scale Schoenwaelder, "Information Model for Large-Scale
Measurement Platforms (LMAP)", draft-ietf-lmap- Measurement Platforms (LMAP)", draft-ietf-lmap-
information-model-06 (work in progress), July 2015. information-model-06 (work in progress), July 2015.
[I-D.ietf-lmap-yang] [I-D.ietf-lmap-yang]
Schoenwaelder, J. and V. Bajpai, "A YANG Data Model for Schoenwaelder, J. and V. Bajpai, "A YANG Data Model for
LMAP Measurement Agents", draft-ietf-lmap-yang-01 (work in LMAP Measurement Agents", draft-ietf-lmap-yang-01 (work in
progress), July 2015. progress), July 2015.
[I-D.ietf-netconf-call-home] [I-D.ietf-netconf-call-home]
Watsen, K., "NETCONF Call Home and RESTCONF Call Home", Watsen, K., "NETCONF Call Home and RESTCONF Call Home",
draft-ietf-netconf-call-home-08 (work in progress), June draft-ietf-netconf-call-home-11 (work in progress),
2015. September 2015.
[I-D.ietf-netconf-restconf] [I-D.ietf-netconf-restconf]
Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", draft-ietf-netconf-restconf-06 (work in Protocol", draft-ietf-netconf-restconf-08 (work in
progress), June 2015. progress), October 2015.
[I-D.ietf-netconf-server-model] [I-D.ietf-netconf-server-model]
Watsen, K. and J. Schoenwaelder, "NETCONF Server and Watsen, K. and J. Schoenwaelder, "NETCONF Server and
RESTCONF Server Configuration Models", draft-ietf-netconf- RESTCONF Server Configuration Models", draft-ietf-netconf-
server-model-06 (work in progress), February 2015. server-model-08 (work in progress), October 2015.
[I-D.starkcarey-lmap-protocol-criteria] [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Stark, B. and T. Carey, "LMAP Protocol Selection Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
Criteria", draft-starkcarey-lmap-protocol-criteria-01 RFC2119, March 1997,
(work in progress), March 2015. <http://www.rfc-editor.org/info/rfc2119>.
[RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
Network Configuration Protocol (NETCONF)", RFC 6020, the Network Configuration Protocol (NETCONF)", RFC 6020,
October 2010. DOI 10.17487/RFC6020, October 2010,
<http://www.rfc-editor.org/info/rfc6020>.
[RFC7223] Bjorklund, M., "A YANG Data Model for Interface [RFC7223] Bjorklund, M., "A YANG Data Model for Interface
Management", RFC 7223, May 2014. Management", RFC 7223, DOI 10.17487/RFC7223, May 2014,
<http://www.rfc-editor.org/info/rfc7223>.
[RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
(HTTP/1.1): Message Syntax and Routing", RFC 7230, June Protocol (HTTP/1.1): Message Syntax and Routing", RFC
2014. 7230, DOI 10.17487/RFC7230, June 2014,
<http://www.rfc-editor.org/info/rfc7230>.
[RFC7277] Bjorklund, M., "A YANG Data Model for IP Management", RFC [RFC7277] Bjorklund, M., "A YANG Data Model for IP Management", RFC
7277, June 2014. 7277, DOI 10.17487/RFC7277, June 2014,
<http://www.rfc-editor.org/info/rfc7277>.
[RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for [RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for
System Management", RFC 7317, August 2014. System Management", RFC 7317, DOI 10.17487/RFC7317, August
2014, <http://www.rfc-editor.org/info/rfc7317>.
Appendix A. Response to Protocol Comparison Criteria
A set of control and report protocol comparison criteria has been
defined in [I-D.starkcarey-lmap-protocol-criteria]. This section
compares the usage of RESTCONF against the criteria.
CP-MUST-1 yes (RFC6241 RFC6242, RFC5539),
[I-D.ietf-netconf-restconf]
CP-MUST-2 yes [I-D.ietf-netconf-call-home]
CP-MUST-3 yes SSH / TLS (NETCONF), TLS (RESTCONF)
CP-MUST-4 yes YANG data models [RFC6020] have a well defined
versioning and extension model
CP-DIFF-1 1
CP-DIFF-2 1
CP-DIFF-3 yes
CP-DIFF-4 yes (NETCONF|RESTCONF) call home
CP-DIFF-5 (underspecified - it is JSON or XML over HTTP/TLS)
CP-DIFF-6 (underspecified - it is JSON or XML over HTTP/TLS)
CP-DIFF-7 HTTP and JSON/XML are pretty much everywhere
CP-DIFF-8 YANG tools are out there and the rest will develop, HTTP
and TLS are pretty well understood
CP-DIFF-9 yes
CP-DIFF-10 many tools out there to create REST code, YANG tools
available
CP-DIFF-11 yes, YANG RFC 6020 data models have a version model
CP-DIFF-12 additional YANG modules can augment the standard data
model
CP-DIFF-13 JSON and XML, CBOR in the making
RP-MUST-1 yes [I-D.ietf-netconf-call-home]
RP-MUST-2 SSH / TLS (NETCONF), TLS (RESTCONF)
RP-MUST-3 YANG RFC 6020 data models have a version model
RP-DIFF-1 TCP
RP-DIFF-2 yes
RP-DIFF-3 (underspecified - it is HTTP over TLS)
RP-DIFF-4 yes
RP-DIFF-5 yes
RP-DIFF-6 yes (as part of HTTP encoding negotiations)
RP-DIFF-7 (underspecified - it is JSON or XML over HTTP/TLS)
RP-DIFF-8 HTTP and JSON/XML are pretty much everywhere
RP-DIFF-9 many tools out there to create REST code, YANG tools
available
RP-DIFF-10 yes
RP-DIFF-11 many tools out there to create REST code, YANG tools
available
RP-DIFF-12 JSON and XML, CBOR in the making [RFC7594] Eardley, P., Morton, A., Bagnulo, M., Burbridge, T.,
Aitken, P., and A. Akhter, "A Framework for Large-Scale
Measurement of Broadband Performance (LMAP)", RFC 7594,
DOI 10.17487/RFC7594, September 2015,
<http://www.rfc-editor.org/info/rfc7594>.
Appendix B. Example RESTCONF Control Protocol Exchange Appendix A. Example RESTCONF Control Protocol Exchange
Below is a YANG tree diagram of a part of the data model covering Below is a YANG tree diagram of a part of the data model covering
schedules. This is taken from [I-D.ietf-lmap-yang]. schedules. This is taken from [I-D.ietf-lmap-yang].
module: ietf-lmap module: ietf-lmap
+--rw lmap +--rw lmap
+--rw schedules +--rw schedules
+--rw schedule* [name] +--rw schedule* [name]
+--rw name string +--rw name string
+--rw event leafref +--rw event leafref
skipping to change at page 8, line 21 skipping to change at page 6, line 41
<name>icmp-latency-hourly</name> <name>icmp-latency-hourly</name>
<task>icmp-latency-measurement</task> <task>icmp-latency-measurement</task>
<destination>daily</destination> <destination>daily</destination>
</action> </action>
<execution-mode>sequential</execution-mode> <execution-mode>sequential</execution-mode>
</schedule> </schedule>
</schedules> </schedules>
</lmap> </lmap>
Below is an example showing how RESTCONF can be used to create the Below is an example showing how RESTCONF can be used to create the
above schedule. The prefix C: indicates the controller, the prefix above schedule. The prefix C: indicates the Controller, the prefix
M: indicates the measurement agent. This example uses a JSON M: indicates the Measurement Agent. This example uses a JSON
encoding (and note that much of the white-space can be removed, this encoding (and note that much of the white-space can be removed, this
is only there to help with readability). is only there to help with readability).
C: POST /restconf/data/ietf-lmap:lmap/schedules HTTP/1.1 C: POST /restconf/data/ietf-lmap:lmap/schedules HTTP/1.1
C: Host: example.com C: Host: example.com
C: Content-Type: application/yang.data+json C: Content-Type: application/yang.data+json
C: C:
C: { C: {
C: "ietf-lmap:schedule": { C: "ietf-lmap:schedule": {
C: "name": "hourly-schedule", C: "name": "hourly-schedule",
skipping to change at page 9, line 32 skipping to change at page 7, line 32
C: } C: }
M: HTTP/1.1 201 Created M: HTTP/1.1 201 Created
M: Date: Mon, 26 Mar 2015 17:01:00 GMT M: Date: Mon, 26 Mar 2015 17:01:00 GMT
M: Server: example-server M: Server: example-server
M: Location: https://example.com/restconf/data M: Location: https://example.com/restconf/data
M: /ietf-lmap:lmap/schedules/schedule=hourly-schedule M: /ietf-lmap:lmap/schedules/schedule=hourly-schedule
M: Last-Modified: Mon, 26 Mar 2015 17:01:00 GMT M: Last-Modified: Mon, 26 Mar 2015 17:01:00 GMT
M: ETag: b3a3e673be2 M: ETag: b3a3e673be2
Appendix C. Example RESTCONF Report Protocol Exchange Appendix B. Example RESTCONF Report Protocol Exchange
The first step taken by the collector is to lookup the event stream
resource.
C: GET /restconf/data/ietf-restconf-monitoring:restconf-state/ Below is an example showing how a Measurement Agent can submit
C: /streams/stream=NETCONF/encoding=json/events HTTP/1.1 results to a Collector running an RESTCONF server. The prefix C:
C: Host: example.com indicates the Collector, the prefix M: indicates the Measurement
C: Accept: application/yang.data+xml Agent.
M: HTTP/1.1 200 OK M: POST /restconf/operations/ietf-lmap-report:report HTTP/1.1
M: Content-Type: application/yang.api+xml M: Host: example.com
M: Content-Type: application/yang.operation+xml
M: M:
M: <events M: <input>
M: xmlns="urn:ietf:params:xml:ns:yang:ietf-restconf-monitoring"> M: <report xmlns="urn:ietf:params:xml:ns:yang:ietf-lmap-report">
M: https://example.com/streams/NETCONF-json M: <date>2015-10-28T13:27:42+02:00</date>
M: </events> M: <agent-id>550e8400-e29b-41d4-a716-446655440000</agent-id>
M: <group-id>wireless measurement at the north-pole</group-id>
Once the event stream resource is known (information might be M: <task>
cached), the collector subscribes to the event stream resource. M: <name>icmp-latency-measurement</name>
M: <metric>
C: GET /streams/NETCONF-json HTTP/1.1 M: <uri>urn:....</uri>
C: Host: example.com M: </metric>
C: Accept: text/event-stream M: <header>
C: Cache-Control: no-cache M: <column>target</column>
C: Connection: keep-alive M: <column>rtt</column>
M: </header>
M: <row>
M: <start-time>2015-03-25T00:00:55+00:00</start-time>
M: <value>192.0.2.1</value>
M: <value>42</value>
M: </row>
M: <row>
M: <start-time>2015-03-25T00:00:56+00:00</start-time>
M: <value>192.0.2.1</value>
M: <value>42</value>
M: </row>
M: </task>
M: </report>
M: </input>
M: data: { C: HTTP/1.1 200 OK
M: data: "ietf-restconf:notification": {
M: data: "event-time": "2015-03-25T00:01:00+00:00",
M: data: "ietf-lmap:report": {
M: data: "date": "2015-03-25T00:01:00+00:00",
M: data: "agent-id": "xxx",
M: data: "header": {
M: data: "column": "target",
M: data: "column": "rtt"
M: data: }
M: data: "row": {
M: data: "start": "2015-03-25T00:00:55+00:00",
M: data: "value": "192.0.2.1",
M: data: "value": 42
M: data: }
M: data: "row": {
M: data: "start": "2015-03-25T00:00:56+00:00",
M: data: "value": "192.0.2.2",
M: data: "value": 24
M: data: }
M: data: }
M: data: }
M: data: }
Authors' Addresses Authors' Addresses
Juergen Schoenwaelder Juergen Schoenwaelder
Jacobs University Bremen Jacobs University Bremen
Email: j.schoenwaelder@jacobs-university.de Email: j.schoenwaelder@jacobs-university.de
Vaibhav Bajpai Vaibhav Bajpai
Jacobs University Bremen Jacobs University Bremen
 End of changes. 38 change blocks. 
212 lines changed or deleted 118 lines changed or added

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