idnits 2.17.1
draft-mst-lgapi-07.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 date (October 30, 2017) is 2364 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
** Obsolete normative reference: RFC 2858 (Obsoleted by RFC 4760)
** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259)
** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110)
-- Obsolete informational reference (is this intentional?): RFC 7320
(Obsoleted by RFC 8820)
Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group M. Stubbig
3 Internet-Draft Independent
4 Intended status: Informational October 30, 2017
5 Expires: May 3, 2018
7 Looking Glass API
8 draft-mst-lgapi-07
10 Abstract
12 This document introduces an application programming interface (API)
13 to the web-based "Network Looking Glass" software. Its purpose is to
14 provide application programmers uniform access to the Looking Glass
15 service and to analyze standardized response.
17 The API interface is supposed to provide the same level of
18 information as web-based interfaces, but in a computer-readable
19 format.
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 https://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, 2018.
38 Copyright Notice
40 Copyright (c) 2017 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 (https://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 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 3
57 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
58 1.3. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 3
59 1.4. Examples . . . . . . . . . . . . . . . . . . . . . . . . 3
60 2. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 4
61 2.1. Method Parameters . . . . . . . . . . . . . . . . . . . . 4
62 2.2. Query Parameters . . . . . . . . . . . . . . . . . . . . 4
63 2.3. Response . . . . . . . . . . . . . . . . . . . . . . . . 6
64 3. API functions . . . . . . . . . . . . . . . . . . . . . . . . 8
65 3.1. Diagnostic commands . . . . . . . . . . . . . . . . . . . 8
66 3.2. Informational commands . . . . . . . . . . . . . . . . . 9
67 3.3. Administrative commands . . . . . . . . . . . . . . . . . 10
68 3.4. Extensible commands . . . . . . . . . . . . . . . . . . . 13
69 4. Miscellaneous . . . . . . . . . . . . . . . . . . . . . . . . 13
70 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
71 6. Security Consideration . . . . . . . . . . . . . . . . . . . 13
72 6.1. Abuse Potential . . . . . . . . . . . . . . . . . . . . . 13
73 6.2. Authentication . . . . . . . . . . . . . . . . . . . . . 14
74 6.3. Minimal information . . . . . . . . . . . . . . . . . . . 14
75 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
76 7.1. Normative References . . . . . . . . . . . . . . . . . . 14
77 7.2. Informative References . . . . . . . . . . . . . . . . . 15
78 Appendix A. JSend . . . . . . . . . . . . . . . . . . . . . . . 15
79 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16
81 1. Introduction
83 Many Internet service providers (ISPs) and Internet exchange points
84 (IXPs) offer a complimentary web page to the general public, which
85 gives insights to the backbone routing table, BGP neighbor
86 information, or offered routes.
88 The visitor may also execute a ping or traceroute command to a random
89 target address. Some ISPs even offer information about their
90 multicast routing table including the mtrace command. The amount and
91 type of offered information is not limited.
93 The service is mostly used for the purpose of troubleshooting and is
94 known under the term of "Looking Glass". The development of various
95 Looking Glass software has led to different systems in usage, syntax,
96 style, and in offered information. The difference is of minor
97 interest to human users, but accessing a Looking Glass web page by
98 script is complicated, inefficient, and error-prone.
100 Accessing a Looking Glass service by script is required for repeating
101 tasks. It could be a monitoring system which validates link
102 availability or bandwidth usage.
104 This leads to the requirement of a unified access method to the
105 information provided by a Looking Glass. This document is a proposal
106 of an application programmers interface (API), which provides a
107 common schema, list of arguments, and options when accessing a
108 Looking Glass service.
110 The transport protocol of choice is encrypted HTTP, the style of
111 operation is REST, and the response format is JSON [RFC7159].
113 The Looking Glass API is described as a language-independent concept.
114 Consequently, any programming language, which satisfies API commands
115 listed in the following chapters, is acceptable.
117 1.1. Background
119 The requirement of a uniform access to a Looking Glass service
120 becomes important when multiple Looking Glasses are part of a
121 monitoring system. Implementing a web client and HTTP-parser for
122 every kind of web-based Looking Glass is a time consuming workaround,
123 however, the Looking Glass API is a much more viable, compatible, and
124 scalable solution.
126 1.2. Terminology
128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
130 document are to be interpreted as described in RFC 2119 [RFC2119].
132 1.3. Syntax Notation
134 This specification uses the JavaScript Object Notation (JSON) of
135 [RFC7159] arranged as JSend [JSend] compliant response.
137 1.4. Examples
139 All URLs in this documentation use the reserved sample domain of
140 "example.net" as defined in [RFC6761] section 6.5.
142 IPv4 addresses use the documenational block of 192.0.2.0/24 [RFC5737]
143 and IPv6 addresses reside in the reserved prefix of 2001:DB8::/32
145 [RFC3849]. BGP Autonomous System numbers are chosen from the private
146 AS range defined in [RFC6996].
148 The printed examples skip some required parameters for reasons of
149 simplicity.
151 2. Operation
153 An API client issues a query using the HTTP GET method to request a
154 specific resources from the API server. The resource is a URI and
155 can be informational or a command execution. The client must present
156 all necessary parameters for the API server to execute the command on
157 the selected router. Every API call is stateless and independent of
158 the previous one.
160 The "API call" is a request from the client, which specifies a pre-
161 defined operation ("API function") that the server will execute on a
162 selected router. The "command" is a task executed on the router and
163 initiated by the server on behalf of the client. The type and scope
164 of all commands is defined and limited by the server. The client
165 MUST NOT be able to execute random commands on the targeting router.
166 There MUST NOT be any direct communication between the client and the
167 router.
169 After the execution of the command on the selected router has
170 finished, the server replies to the client if the operation has
171 either succeeded, failed or timed out. The response is sent to the
172 API client in JSON format. The communication protocol used between
173 the server and router is not specified by this document; any method
174 (e.g. Telnet, SSH, NETCONF, YANG, serial console) is acceptable.
176 All parameters and its values are case insensitive.
178 2.1. Method Parameters
180 Method parameters are mandatory components of the URI and placed in
181 the "path" section in terms of [RFC7320]. Basically, the method
182 parameters specify the API call and determine which command the
183 client wants executed on the selected router.
185 2.2. Query Parameters
187 Query parameters are optional components of the URI and placed in the
188 "query" section in terms of [RFC7320]. Generally, the query
189 parameters are additional instructions for the requested command.
191 protocol
192 Restrict the command and method parameters to use the specified
193 protocol and version. Protocol is selected as "Address Family
194 Identifier" [IANA-AFN] [RFC2858] and optional "Subsequent Address
195 Family Identifier" [IANA-SAFI] separated by comma.
196 Default value is 1,1 (IP version 4, unicast).
197 JSON data type is String.
198 Examples:
200 * protocol=2,1 (IP version 6, unicast)
202 * protocol=26 (MPLS, no SAFI used)
204 router
205 Run the command on the router identified by its name. This is not
206 necessarily the routers hostname as long as the Looking Glass
207 software recognizes it.
208 Default value is the first router in the list of available
209 routers.
210 JSON data type is String.
211 Example: router=rbgn06.example.net
213 routerid
214 Run the command on this router identified by its position in the
215 list of available routers.
216 Default value is "0".
217 JSON data type is Number.
218 Example: routerid=8
220 random
221 Append a random string to prevent the client (or an intermediate
222 proxy) from caching the response. The API server must ignore its
223 value.
224 No default value.
225 JSON data type is String.
226 Example: random=517A93B50
228 runtime
229 Stop executing the command after the runtime limit (in seconds) is
230 exceeded. A value of 0 disables the limit.
231 Default value is "30".
232 JSON data type is Number.
233 Example: runtime=60
235 format
236 Request the server to provide the output (if any) in the selected
237 format. Specify multiple formats separated by comma in descending
238 order of preference. See Section 3.3.2 for more details.
239 Default value is "text/plain" (raw/unformatted output).
241 JSON data type is String.
242 Example: format=application/yang,text/plain
244 2.3. Response
246 The HTTP response header SHOULD set an appropriate HTTP status code
247 as defined in [RFC7231] and MUST set the Content-Type to
248 "application/json".
250 The HTTP body contains details and error descriptions. The response
251 text MUST comply with the JSON syntax specification JSend [JSend],
252 which is briefly explained in appendix JSend. Consequently every
253 response MUST contain a "status" field of either "success", "fail",
254 or "error", that are explained in the following sections.
256 2.3.1. Success
258 A successful response MUST set the "status" field to "success". It
259 MUST also contain a "data" object including the following
260 information:
262 performed_at
263 combined date and time in UTC ISO 8601 [iso8601] indicating when
264 the operation finished. This information MUST be present.
266 runtime
267 amount of seconds (wallclock) used to run the command. This
268 information MUST be present.
270 router
271 the name of the router, that executed the command. This
272 information MAY be present.
274 output
275 output of the command in a format that was requested by the client
276 or defaults to raw output as it appeared on the routers command
277 line interface (CLI). It might even be blank if the command did
278 not produce any output. This information SHOULD be present.
280 format
281 selected output format by the server. The client might request
282 multiple formats, so that the "Looking Glass" server has to choose
283 the best option and tell the client which format was selected.
284 This information SHOULD be present (or defaults to "text/plain" if
285 missing).
287 Adding more information to the response is permitted and MUST be
288 placed inside the "data" object.
290 The HTTP status code SHOULD be 200.
292 Example:
294 HTTP/1.1 200 OK
295 Content-Type: application/json
296 {
297 "status" : "success",
298 "data" : {
299 "router" : "route-server.lookingglass.example.net"
300 "performed_at" : "2014-10-15T17:15:34Z",
301 "runtime" : 2.63,
302 "output" : [
303 "full raw output from the observing router..."
304 ],
305 "format" : "text/plain"
306 }
307 }
309 2.3.2. Fail
311 A status of "fail" indicates that the selected command was executed
312 on the router but failed to succeed. The response message MUST set
313 the "status" field to "fail" and MUST contain the "data" object with
314 command-specific content, that is listed in Section 2.3.1.
316 The HTTP status code SHOULD be 200.
318 Example:
320 HTTP/2.0 200 OK
321 {
322 "status" : "fail",
323 "data" : {
324 "performed_at" : "2014-10-18T20:04:37Z",
325 "runtime" : 10.37,
326 "output" : [
327 "Sending 5, 100-byte ICMP Echos to 192.0.2.5",
328 ".....",
329 "Success rate is 0 percent (0/5)"
330 ],
331 "format" : "text/plain",
332 "router" : "route-server.lookingglass.example.net"
333 }
334 }
336 2.3.3. Error
338 The status "error" represents an error which occurred in processing
339 the request or the command timed out. The response message MUST set
340 the "status" field to "error" and MUST contain the "message" key,
341 that keeps a meaningful message, explaining what went wrong.
343 The response MAY contain the "data" key, with required values listed
344 in Section 2.3.1. It MAY also include a "code" field, that carries a
345 numeric code corresponding to the error.
347 The HTTP status code SHOULD be 400 in case of a client-side error,
348 500 in case of a server-side error or 502 for errors occurring on the
349 target router. Code 504 SHOULD be used when a command timed out.
351 Example:
353 HTTP/1.1 400 Bad Request
354 {
355 "status" : "error",
356 "message" : "Unrecognized host or address."
357 }
359 3. API functions
361 The Looking Glass API provides functions that are either mandatory or
362 optional to implement. The same principle applies to the web-based
363 Looking Glass.
365 It is not possible for any API function to modify the server's state.
366 Therefore, all HTTP methods are GET operations.
368 Variables are templated and expanded in harmony of [RFC6570].
370 3.1. Diagnostic commands
372 3.1.1. Ping
374 Send echo messages to validate the reachability of a remote host and
375 measure round-trip time. The "ping" command MAY use the ICMP
376 protocol, but any protocol that satisfies the requirement is
377 acceptable.
379 Implementation of the ping command is mandatory.
381 Syntax: https://lg.example.net/api/v1/ping/{addr}
382 Example:
384 https://lg.example.net/api/v1/ping/2001:DB8::35?protocol=2,1
386 3.1.2. Traceroute
388 Trace path from the executing router to the destination host and list
389 all intermediate hops.
391 Implementation of the traceroute command is optional.
393 Syntax: https://lg.example.net/api/v1/traceroute/{addr}
395 Example:
397 https://lg.example.net/api/v1/traceroute/192.0.2.1?routerid=5
399 3.2. Informational commands
401 3.2.1. show route
403 Retrieve information about a specific subnet from the routing table.
405 Implementation of the "show route" command is mandatory.
407 Syntax: https://lg.example.net/api/v1/show/route/{addr}
409 Example:
411 https://lg.example.net/api/v1/show/route/2001:DB8::/48?protocol=2,1
413 3.2.2. show bgp
415 Display matching record from BGP routing table. This SHOULD include
416 networks, next hop and MAY include metric, local preference, path
417 list, weight, etc.
419 Implementation of the "show bgp" command is optional.
421 Syntax: https://lg.example.net/api/v1/show/bgp/{addr}
423 Example:
425 https://lg.example.net/api/v1/show/bgp/192.0.2.0/24
427 3.2.3. show bgp summary
429 Print a summary of BGP neighbor status. This MAY include neighbor
430 BGP ID, autonomous system number, duration of peering, number of
431 received prefixes, etc.
433 Implementation of the "show bgp summary" command is optional.
435 Syntax: https://lg.example.net/api/v1/show/bgp/summary
437 Example:
439 https://example.net/api/v1/show/bgp/summary?protocol=2&routerid=3
441 3.2.4. show bgp neighbors
443 Provide detailed information on BGP neighbor connections. Available
444 details MAY include neighbor BGP ID, advertised networks, learned
445 networks, autonomous system number, capabilities, protocol,
446 statistics, etc.
448 Implementation of the "show bgp neighbors" command is optional.
450 Syntax: https://lg.example.net/api/v1/show/bgp/neighbors/{addr}
452 Example:
454 https://lg.example.net/api/v1/show/bgp/neighbors/192.0.2.226
456 3.3. Administrative commands
458 The following administrative commands MUST be included in the
459 implementation.
461 3.3.1. router list
463 The command provides a full list of routers that are available for
464 command execution. This list includes the router ID and its name.
465 It is equivalent to the common "router" HTML drop-down form element
466 and contains the same information.
468 Syntax: https://lg.example.net/api/v1/routers
469 Example response:
471 {
472 "status" : "success",
473 "data" : {
474 "routers" : [
475 "route-server.lookingglass.example.net",
476 "customer-edge.lookingglass.example.net",
477 "provider-edge.lookingglass.example.net"
478 ],
479 "performed_at" : "2014-10-19T20:07:01Z",
480 "runtime" : 0.73
481 }
482 }
484 3.3.2. router details
486 List additional information about the selected router, specified by
487 its router ID. The response MUST contain the routers hostname and
488 router ID. The response MAY contain more details like output format,
489 country code, city, administrative contact, vendor and model.
491 Available output formats are specified by Internet media type as of
492 [RFC6838] and listed in [IANA-MT]. If the routers supports multiple
493 formats, they are separated by comma.
495 The router might provide output formats, that are not yet registered
496 or listed in [IANA-MT]. RFC6838 [RFC6838] provides a tree for
497 unregistered subtypes. For example, output in NETCONF format could
498 use "text/x.netconf".
500 Missing output format defaults to "text/plain", which is a copy of
501 the raw command-line output.
503 Syntax: https://lg.example.net/api/v1/routers/{number}
505 Example query:
507 https://lg.example.net/api/v1/routers/1
508 Example response:
510 {
511 "status" : "success",
512 "data" : {
513 "id" : 1,
514 "name" : "customer-edge.lookingglass.example.net",
515 "format" : "text/plain,text/x.netconf",
516 "country" : "de",
517 "autonomous_system" : 64512
518 }
519 }
521 3.3.3. commands
523 This function provides a full list of commands that are available for
524 execution. The list includes mandatory, optional, and additional
525 (Section 3.4) commands. It is equivalent to the "command" HTML drop-
526 down or radio-button form element and contains the same information.
528 The list is formatted as "commands" array containing one object per
529 command. This object contains informative strings about the current
530 command: href, arguments, description and command.
532 Syntax: https://lg.example.net/api/v1/commands
534 Example response:
536 {
537 "status" : "success",
538 "data" : {
539 "commands" : [
540 {
541 "href" : "https://lg.example.net/api/v1/show/route",
542 "arguments" : "{addr}",
543 "description" : "Print records from IP routing table",
544 "command" : "show route"
545 },
546 {
547 "href" : "https://lg.example.net/api/v1/traceroute",
548 "arguments" : "{addr}",
549 "description" : "Trace route to destination host",
550 "command" : "traceroute"
551 }
552 ]
553 }
554 }
556 3.4. Extensible commands
558 The list of commands MAY be expanded as long as the principles of
559 this document are observed.
561 For example, a Looking Glass provider may not be offering BGP-related
562 commands because of an OSPF-based network.
564 The sample command might be:
566 https://lg.example.net/api/v1/show/ospf/database
568 4. Miscellaneous
570 The network traffic sent by a "Looking Glass" is not appropriate when
571 measuring Service Level Agreements or validating Quality of Service
572 setting.
574 If a monitoring system uses the Looking Glass API for reachability
575 checks, it SHOULD NOT rely on the HTTP status codes but on the
576 "status" message field inside the HTTP body.
578 5. IANA Considerations
580 none
582 6. Security Consideration
584 The use of HTTPS is REQUIRED to ensure a high level of security,
585 privacy, and confidentiality during transit.
587 6.1. Abuse Potential
589 The main goal of the Looking Glass API is the automated usage of the
590 Looking Glass service. This allows the scripting of API calls, which
591 could be used as a distributed Denial of Service (DDoS) attack.
592 Interestingly, the attacked system recognizes the attack originating
593 from various ISPs core network.
595 It is RECOMMENDED that implementers of the Looking Glass API take
596 steps to mitigate the above described abuse. The strategy can
597 include blocking or rate-limiting by client IP address or target IP
598 network.
600 6.2. Authentication
602 Authentication is not a requirement because the current Looking Glass
603 web services are usable without authentication. Requests to the
604 proposed API service MAY be authenticated by any method. The
605 decision is up to the implementers security requirements.
607 6.3. Minimal information
609 Some of the described commands provide a detailed insight into the
610 providers network. It is therefore up to the implementer's security
611 policy to dismiss commands that are marked as "optional" or restrict
612 commands that are marked as "mandatory".
614 7. References
616 7.1. Normative References
618 [IANA-AFN]
619 IANA, "Address Family Numbers", 2015,
620 .
623 [IANA-MT] IANA, "Media Types", 2015,
624 .
627 [IANA-SAFI]
628 IANA, "Subsequent Address Family Identifier (SAFI)
629 Parameters", 2015,
630 .
632 [JSend] OmniTI Labs, "JSend", 2013,
633 .
635 [RFC2858] Bates, T., Rekhter, Y., Chandra, R., and D. Katz,
636 "Multiprotocol Extensions for BGP-4", RFC 2858,
637 DOI 10.17487/RFC2858, June 2000,
638 .
640 [RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M.,
641 and D. Orchard, "URI Template", RFC 6570,
642 DOI 10.17487/RFC6570, March 2012,
643 .
645 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
646 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March
647 2014, .
649 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
650 Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
651 DOI 10.17487/RFC7231, June 2014,
652 .
654 7.2. Informative References
656 [iso8601] International Organization for Standardization, "Date and
657 time format--ISO 8601", 2006,
658 .
660 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
661 Requirement Levels", BCP 14, RFC 2119,
662 DOI 10.17487/RFC2119, March 1997,
663 .
665 [RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix
666 Reserved for Documentation", RFC 3849,
667 DOI 10.17487/RFC3849, July 2004,
668 .
670 [RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks
671 Reserved for Documentation", RFC 5737,
672 DOI 10.17487/RFC5737, January 2010,
673 .
675 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names",
676 RFC 6761, DOI 10.17487/RFC6761, February 2013,
677 .
679 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
680 Specifications and Registration Procedures", BCP 13,
681 RFC 6838, DOI 10.17487/RFC6838, January 2013,
682 .
684 [RFC6996] Mitchell, J., "Autonomous System (AS) Reservation for
685 Private Use", BCP 6, RFC 6996, DOI 10.17487/RFC6996, July
686 2013, .
688 [RFC7320] Nottingham, M., "URI Design and Ownership", BCP 190,
689 RFC 7320, DOI 10.17487/RFC7320, July 2014,
690 .
692 Appendix A. JSend
694 According to [JSend], "JSend is a specification that lays down some
695 rules for how JSON responses from web servers should be formatted.
696 JSend focuses on application-level (as opposed to protocol- or
697 transport-level) messaging which makes it ideal for use in REST-style
698 applications and APIs."
700 A basic JSend-compliant response MUST contain a "status" key and
701 SHOULD contain "data", "message" and "code" keys dependent on the
702 status value. The following table lists the required and optional
703 keys.
705 +---------+-----------------+---------------+
706 | Type | Required keys | Optional keys |
707 +---------+-----------------+---------------+
708 | success | status, data | |
709 | fail | status, data | |
710 | error | status, message | code, data |
711 +---------+-----------------+---------------+
713 Table 1: Type and keys in JSend response
715 Author's Address
717 Markus Stubbig
718 Independent
719 Germany
721 Email: stubbig.ietf@gmail.com