idnits 2.17.1 draft-ietf-ipfix-text-adt-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 (July 15, 2014) is 3571 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) == Missing Reference: 'WSP' is mentioned on line 157, but not defined -- Obsolete informational reference (is this intentional?): RFC 7159 (Obsoleted by RFC 8259) == Outdated reference: A later version (-23) exists of draft-ietf-precis-framework-17 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPFIX Working Group B. Trammell 3 Internet-Draft ETH Zurich 4 Intended status: Standards Track July 15, 2014 5 Expires: January 16, 2015 7 Textual Representation of IPFIX Abstract Data Types 8 draft-ietf-ipfix-text-adt-07.txt 10 Abstract 12 This document defines UTF-8 representations for IPFIX abstract data 13 types, to support interoperable usage of the IPFIX Information 14 Elements with protocols based on textual encodings. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on January 16, 2015. 33 Copyright Notice 35 Copyright (c) 2014 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3. Identifying Information Elements . . . . . . . . . . . . . . 3 53 4. Data Type Encodings . . . . . . . . . . . . . . . . . . . . . 3 54 4.1. octetArray . . . . . . . . . . . . . . . . . . . . . . . 4 55 4.2. unsigned8, unsigned16, unsigned32, and unsigned64 . . . . 4 56 4.3. signed8, signed16, signed32, and signed64 . . . . . . . . 5 57 4.4. float32 and float64 . . . . . . . . . . . . . . . . . . . 6 58 4.5. boolean . . . . . . . . . . . . . . . . . . . . . . . . . 7 59 4.6. macAddress . . . . . . . . . . . . . . . . . . . . . . . 7 60 4.7. string . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 4.8. The dateTime ADTs . . . . . . . . . . . . . . . . . . . . 8 62 4.9. ipv4Address . . . . . . . . . . . . . . . . . . . . . . . 8 63 4.10. ipv6Address . . . . . . . . . . . . . . . . . . . . . . . 9 64 4.11. basicList, subTemplateList, and subTemplateMultiList . . 9 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 67 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 68 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 70 8.2. Informative References . . . . . . . . . . . . . . . . . 11 71 Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . 12 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 74 1. Introduction 76 The IPFIX Information Model[RFC7012] provides a set of abstract data 77 types for the IANA IPFIX Information Element Registry [IANA-IPFIX], 78 which contains a rich set of Information Elements for description of 79 information about network entities and network traffic data, and 80 abstract data types for these Information Elements. The IPFIX 81 Protocol Specification [RFC7011], in turn, defines a big-endian 82 binary encoding for these abstract data types suitable for use with 83 the IPFIX Protocol. 85 However, present and future operations and management protocols and 86 applications may use textual encodings, and generic framing and 87 structure, as in JSON [RFC7159] or XML. A definition of canonical 88 textual encodings for the IPFIX abstract data types would allow this 89 set of Information Elements to be used for such applications, and for 90 these applications to interoperate with IPFIX applications at the 91 Information Element definition level. 93 Note that templating or other mechanisms for data description for 94 such applications and protocols are application-specific, and 95 therefore out of scope for this document: only Information Element 96 identification and value representation are defined here. 98 In most cases where a textual representation will be used, an 99 explicit tradeoff is made for human readability or manipulability 100 over compactness; this assumption is used in defining standard 101 representations of IPFIX ADTs. 103 2. Terminology 105 Capitalized terms defined in the IPFIX Protocol Specification 106 [RFC7011] and the IPFIX Information Model [RFC7012] are used in this 107 document as defined in those documents. The key words "MUST", "MUST 108 NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", 109 "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 110 interpreted as described in [RFC2119]. In addition, this document 111 defines the following terminology for its own use: 113 Enclosing Context 114 A textual representation of Information Element values is applied 115 to use the IPFIX Information Model within some existing textual 116 format (e.g. XML [W3C-XML], JSON [RFC7159]). This outer format 117 is referred to as the Enclosing Context within this document. 118 Enclosing Contexts define escaping and quoting rules for 119 represented values. 121 3. Identifying Information Elements 123 The IPFIX Information Element Registry [IANA-IPFIX] defines a set of 124 Information Elements numbered by Information Element Identifiers and 125 named for human-readability. These Information Element Identifiers 126 are meant for use with the IPFIX protocol, and have little meaning 127 when applying the IPFIX Information Element Registry to textual 128 representations. 130 Instead, applications using textual representations of Information 131 Elements use Information Element names to identify them; see 132 Appendix A for examples illustrating this principle. 134 4. Data Type Encodings 136 Each subsection of this section defines a textual encoding for the 137 abstract data types defined in [RFC7012]. This section uses ABNF, 138 including the Core Rules in Appendix B of [RFC5234], to describe the 139 format of textual representations of IPFIX abstract data types. 141 4.1. octetArray 143 If the Enclosing Context defines a representation for binary objects, 144 that representation SHOULD be used. 146 Otherwise, since the goal of textual representation of Information 147 Elements is human-readability over compactness, the values of 148 Information Elements of the octetArray data type are represented as a 149 string of pairs of hexadecimal digits, one pair per byte, in the 150 order the bytes would appear on the wire were the octetArray encoded 151 directly in IPFIX per [RFC7011]. Whitespace may occur between any 152 pair of digits to assist in human readability of the string, but is 153 not necessary. In ABNF: 155 hex-octet = 2HEXDIG 157 octetarray = hex-octet *([WSP] hex-octet) 159 4.2. unsigned8, unsigned16, unsigned32, and unsigned64 161 If the Enclosing Context defines a representation for unsigned 162 integers, that representation SHOULD be used. 164 In the special case that the unsigned Information Element has 165 identifier semantics, and refers to a set of codepoints, either in an 166 external registry, a sub-registry, or directly in the description of 167 the Information Element, then the name or short description for that 168 codepoint as a string MAY be used to improve readability. 170 Otherwise, the values of Information Elements of an unsigned integer 171 type may be represented either as unprefixed base-10 (decimal) 172 strings, as base-16 (hexadecimal) strings prefixed by "0x", or as 173 base-2 (binary) strings prefixed by "0b". In ABNF: 175 unsigned = 1*DIGIT / "0x" 1*HEXDIG / "0b" 1*BIT 177 Leading zeroes are allowed in any representation, and do not signify 178 base-8 (octal) representation. Binary representation is intended for 179 use with Information Elements with flag semantics, but can be used in 180 any case. 182 The encoded value MUST be in range for the corresponding abstract 183 data type or Information Element. Out of range values are 184 interpreted as clipped to the implicit range for the Information 185 Element as defined by the abstract data type, or to the explicit 186 range of the Information Element if defined. Minimum and maximum 187 values for abstract data types are shown in Table 1 below. 189 +------------+---------+----------------------+ 190 | type | minimum | maximum | 191 +------------+---------+----------------------+ 192 | unsigned8 | 0 | 255 | 193 | unsigned16 | 0 | 65536 | 194 | unsigned32 | 0 | 4294967295 | 195 | unsigned64 | 0 | 18446744073709551615 | 196 +------------+---------+----------------------+ 198 Table 1: Ranges for unsigned abstract data types (in decimal) 200 4.3. signed8, signed16, signed32, and signed64 202 If the Enclosing Context defines a representation for signed 203 integers, that representation SHOULD be used. 205 Otherwise, the values of Information Elements of signed integer types 206 are represented as optionally-prefixed base-10 (decimal) strings. In 207 ABNF: 209 sign = "+" / "-" 211 signed = [sign] 1*DIGIT 213 If the sign is omitted, it is assumed to be positive. Leading zeroes 214 are allowed, and do not signify base-8 (octal) encoding. The 215 representation "-0" is explicitly allowed, and is equal to zero. 217 The encoded value MUST be in range for the corresponding abstract 218 data type or Information Element. Out of range values are to be 219 interpreted as clipped to the implicit range for the Information 220 Element as defined by the abstract data type, or to the explicit 221 range of the Information Element if defined. Minimum and maximum 222 values for abstract data types are shown in Table 2 below. 224 +----------+----------------------+----------------------+ 225 | type | minimum | maximum | 226 +----------+----------------------+----------------------+ 227 | signed8 | -128 | +127 | 228 | signed16 | -32768 | +32767 | 229 | signed32 | -2147483648 | +2147483647 | 230 | signed64 | -9223372036854775808 | +9223372036854775807 | 231 +----------+----------------------+----------------------+ 233 Table 2: Ranges for signed abstract data types (in decimal) 235 4.4. float32 and float64 237 If the Enclosing Context defines a representation for floating point 238 numbers, that representation SHOULD be used. 240 Otherwise, the values of Information Elements of float32 or float64 241 types are represented as optionally sign-prefixed, optionally base-10 242 exponent-suffixed, floating point decimal numbers, as in 243 [IEEE.754.2008]. The special strings "NaN", "+inf", and "-inf" 244 represent not a number, positive infinity and negative infinity, 245 respectively. 247 In ABNF: 249 sign = "+" / "-" 251 exponent = "e" [sign] 1*3DIGIT 253 right-decimal = "." 1*DIGIT 255 mantissa = 1*DIGIT [right-decimal] 257 num = [sign] mantissa [exponent] 259 naninf = "NaN" / (sign "inf") 261 float = num / naninf 263 The expressed value is ( mantissa * 10 ^ exponent ). If the sign is 264 omitted, it is assumed to be positive. If the exponent is omitted, 265 it is assumed to be zero. Leading zeroes may appear in the mantissa 266 and/or the exponent. Values MUST be within range for [IEEE.754.2008] 267 single or double precision numbers; finite values outside the 268 approprate range are to be interpreted as clamped to be within the 269 range. Note that no more than three digits are required or allowed 270 for exponents in this encoding due to these ranges. 272 Note that, since this representation is meant for human readability, 273 writers MAY sacrifice precision to use a more human-readable 274 representation of a given value, at the expense of the ability to 275 recover the exact bit pattern at the reader. Therefore, decoders 276 MUST NOT assume that the represented values are exactly compararable 277 for equality. 279 4.5. boolean 281 If the Enclosing Context defines a representation for boolean values, 282 that representation SHOULD be represented. 284 Otherwise, a true boolean value is represented by the literal string 285 "true", and a false boolean value with the literal string "false". 286 In ABNF: 288 boolean-true = "true" 290 boolean-false = "false" 292 boolean = boolean-true / boolean-false 294 4.6. macAddress 296 MAC addresses are represented as IEEE 802 MAC-48 addresses, 297 hexadecimal bytes, most significant byte first, separated by colons. 298 In ABNF: 300 hex-octet = 2HEXDIG 302 macaddress = hex-octet 5( ":" hex-octet ) 304 4.7. string 306 As Information Elements of the string type are simply Unicode strings 307 (encoded as UTF-8 when appearing in Data Sets in IPFIX Messages 308 [RFC7011]), they are represented directly, using the Unicode encoding 309 rules and quoting and escaping rules of the Enclosing Context. 311 If the Enclosing Context cannot natively represent Unicode 312 characters, the escaping facility provided by the Enclosing Context 313 MUST be used for non- representable characters. Additionally, 314 strings containing characters reserved in the Enclosing Context (e.g. 315 control characters, markup characters, quotes) MUST be escaped or 316 quoted according to the rules of the Enclosing Context. 318 It is presumed that the Enclosing Context has sufficient restrictions 319 on the use of Unicode to prevent the unsafe use of non-printing and 320 control characters. As there is no accepted solution for the 321 processing and safe display of mixed-direction strings, mixed- 322 direction strings should be avoided using this encoding. Note also 323 that, since this draft presents no additional requirements for the 324 normalization of Unicode strings, care must be taken when comparing 325 strings using this encoding; direct byte-pattern comparisons are not 326 sufficient for determining whether two strings are equivalent. See 328 [RFC6885] and [I-D.ietf-precis-framework] for more on possible 329 unexpected results and related risks in comparing Unicode strings. 331 4.8. The dateTime ADTs 333 Timestamp abstract data types are represented generally as in 334 [RFC3339], with two important differences. First, all IPFIX 335 timestamps are expressed in terms of UTC, so textual representations 336 of these Information Elements are explicitly in UTC as well. Time 337 zone offsets are therefore not required or supported. Second, there 338 are four timestamp abstract data types, separated by the precision 339 which they can express. Fractional seconds are omitted in 340 dateTimeSeconds, expressed in milliseconds in dateTimeMilliseconds, 341 and so on. 343 In ABNF, taken from [RFC3339] and modified: 345 date-fullyear = 4DIGIT 346 date-month = 2DIGIT ; 01-12 347 date-mday = 2DIGIT ; 01-28, 01-29, 01-30, 01-31 348 time-hour = 2DIGIT ; 00-23 349 time-minute = 2DIGIT ; 00-59 350 time-second = 2DIGIT ; 00-58, 00-59, 00-60 351 time-msec = "." 3DIGIT 352 time-usec = "." 6DIGIT 353 time-nsec = "." 9DIGIT 354 full-date = date-fullyear "-" date-month "-" date-mday 355 integer-time = time-hour ":" time-minute ":" time-second 357 datetimeseconds = full-date "T" integer-time 358 datetimemilliseconds = full-date "T" integer-time "." time-msec 359 datetimemicroseconds = full-date "T" integer-time "." time-usec 360 datetimenanoseconds = full-date "T" integer-time "." time-nsec 362 4.9. ipv4Address 364 IP version 4 addresses are represented in dotted-quad format, most- 365 significant-byte first, as it would in a Uniform Resource Identifier 366 [RFC3986]; the ABNF for an IPv4 address is taken from [RFC3986] and 367 reproduced below: 369 dec-octet = DIGIT ; 0-9 370 / %x31-39 DIGIT ; 10-99 371 / "1" 2DIGIT ; 100-199 372 / "2" %x30-34 DIGIT ; 200-249 373 / "25" %x30-35 ; 250-255 375 ipv4address = dec-octet 3( "." dec-octet ) 377 4.10. ipv6Address 379 IP version 6 addresses are represented as in section 2.2 of 380 [RFC4291], as updated by section 4 of [RFC5952]. The ABNF for an 381 IPv6 address is taken from [RFC3986] and reproduced below, using the 382 ipv4address production from the previous section: 384 ls32 = ( h16 ":" h16 ) / ipv4address 385 ; least-significant 32 bits of address 386 h16 = 1*4HEXDIG 387 ; 16 bits of address represented in hexadecimal 388 ; zeroes to suppressed as in RFC 5952 390 ipv6address = 6( h16 ":" ) ls32 391 / "::" 5( h16 ":" ) ls32 392 / [ h16 ] "::" 4( h16 ":" ) ls32 393 / [ h16 ":" h16 ] "::" 3( h16 ":" ) ls32 394 / [ *2( h16 ":" ) h16 ] "::" 2( h16 ":" ) ls32 395 / [ *3( h16 ":" ) h16 ] "::" h16 ":" ls32 396 / [ *4( h16 ":" ) h16 ] "::" ls32 397 / [ *5( h16 ":" ) h16 ] "::" h16 398 / [ *6( h16 ":" ) h16 ] "::" 400 4.11. basicList, subTemplateList, and subTemplateMultiList 402 These abstract data types, defined for IPFIX Structured Data 403 [RFC6313], do not represent actual data types; they are instead 404 designed to provide a mechanism by which complex structure can be 405 represented in IPFIX below the template level. It is assumed that 406 protocols using textual Information Element representation will 407 provide their own structure. Therefore, Information Elements of 408 these Data Types MUST NOT be used in textual representations. 410 5. Security Considerations 412 The security considerations for the IPFIX Protocol [RFC7011] apply. 414 Implementations of decoders of Information Element values using these 415 representations must take care to correctly handle invalid input, but 416 the encodings presented here are not special in that respect. 418 The encoding specified in this document, and representations that may 419 be built upon it, are specifically not intended for the storage of 420 data. However, since storage of data in the format in which it is 421 exchanged is a very common practice, and the ubiquity of tools for 422 indexing and searching text significantly increases the ease of 423 searching and the risk of privacy-sensitive data being accidentally 424 indexed or searched, the privacy considerations in Section 11.8 of 426 [RFC7011] are especially important to observe when storing data using 427 the encoding specified in this document that was derived from the 428 measurement of network traffic. 430 When using representations based on this encoding to transmit or 431 store network traffic data, consider omitting especially privacy- 432 sensitive values by not representing the columns or keys containing 433 those values, as in black-marker anonymization as discussed in 434 Section 4 of [RFC6235]. Other anonymization techinques described in 435 [RFC6235] may also be useful in these situations. 437 The encodings for all Abstract Data Types other than 'string' are 438 defined in such a way as to be representable in the US-ASCII 439 character set, and therefore should be unproblematic for all 440 Enclosing Contexts. However, the 'string' Abstract Data Type may be 441 vulnerable to problems with ill-formed UTF-8 strings as discussed in 442 section 6.1.6 of [RFC7011]; see [UTF8-EXPLOIT] for background. 444 6. IANA Considerations 446 This document has no considerations for IANA. 448 7. Acknowledgments 450 Thanks to Paul Aitken, Benoit Claise, Andrew Feren, Juergen Quittek, 451 David Black, and the IESG for the review and comments. Thanks to 452 Dave Thaler and Stephan Neuhaus for discussions which improved the 453 floating-point representation section. This work is materially 454 supported by the European Union Seventh Framework Programme under 455 grant agreement 318627 mPlane. 457 8. References 459 8.1. Normative References 461 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 462 Requirement Levels", BCP 14, RFC 2119, March 1997. 464 [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the 465 Internet: Timestamps", RFC 3339, July 2002. 467 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 468 Resource Identifier (URI): Generic Syntax", STD 66, RFC 469 3986, January 2005. 471 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 472 Architecture", RFC 4291, February 2006. 474 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 475 Specifications: ABNF", STD 68, RFC 5234, January 2008. 477 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 478 Address Text Representation", RFC 5952, August 2010. 480 [RFC7011] Claise, B., Trammell, B., and P. Aitken, "Specification of 481 the IP Flow Information Export (IPFIX) Protocol for the 482 Exchange of Flow Information", STD 77, RFC 7011, September 483 2013. 485 8.2. Informative References 487 [RFC6235] Boschi, E. and B. Trammell, "IP Flow Anonymization 488 Support", RFC 6235, May 2011. 490 [RFC6313] Claise, B., Dhandapani, G., Aitken, P., and S. Yates, 491 "Export of Structured Data in IP Flow Information Export 492 (IPFIX)", RFC 6313, July 2011. 494 [RFC6885] Blanchet, M. and A. Sullivan, "Stringprep Revision and 495 Problem Statement for the Preparation and Comparison of 496 Internationalized Strings (PRECIS)", RFC 6885, March 2013. 498 [RFC7012] Claise, B. and B. Trammell, "Information Model for IP Flow 499 Information Export (IPFIX)", RFC 7012, September 2013. 501 [RFC7013] Trammell, B. and B. Claise, "Guidelines for Authors and 502 Reviewers of IP Flow Information Export (IPFIX) 503 Information Elements", BCP 184, RFC 7013, September 2013. 505 [RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data 506 Interchange Format", RFC 7159, March 2014. 508 [I-D.ietf-precis-framework] 509 Saint-Andre, P. and M. Blanchet, "PRECIS Framework: 510 Preparation and Comparison of Internationalized Strings in 511 Application Protocols", draft-ietf-precis-framework-17 512 (work in progress), May 2014. 514 [W3C-XML] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and 515 F. Yergeau, "W3C Recommendation: Extensible Markup 516 Language (XML) 1.0 (Fifth Edition)", September 2008. 518 [IEEE.754.2008] 519 Instute of Electrical and Electronic Engineers, , 520 "Standard for Floating-Point Arithmetic (IEEE Standard 521 754)", August 2008. 523 [IANA-IPFIX] 524 Internet Assigned Numbers Authority, , "IP Flow 525 Information Export Information Elements 526 (http://www.iana.org/assignments/ipfix/ipfix.xml)", 527 November 2012. 529 [UTF8-EXPLOIT] 530 Davis, M. and M. Suignard, "Unicode Technical Report #36: 531 Unicode Security Considerations", July 2012. 533 Appendix A. Example 535 In this section, we examine an IPFIX Template and a Data Record 536 defined by that Template, and show how that Data Record would be 537 represented in JSON according to the specification in this document. 538 Note that this is specifically NOT a recommendation for a particular 539 representation, merely an illustration of the encodings in this 540 document; the quoting and formatting in the example are JSON- 541 specific. 543 Figure 1 shows a Template in IESpec format as defined in section 10.1 544 of [RFC7013]; a corresponding JSON Object representing a record 545 defined by this template in the text format specified in this 546 document is shown in Figure 2. 548 flowStartMilliseconds(152)[8] 549 flowEndMilliseconds(153)[8] 550 octetDeltaCount(1)[4] 551 packetDeltaCount(2)[4] 552 sourceIPv6Address(27)[4]{key} 553 destinationIPv6Address(28)[4]{key} 554 sourceTransportPort(7)[2]{key} 555 destinationTransportPort(11)[2]{key} 556 protocolIdentifier(4)[1]{key} 557 tcpControlBits(6)[1] 558 flowEndReason(136)[1] 560 Figure 1: Sample flow template in IESpec format 562 { 563 "flowStartMilliseconds": "2012-11-05T18:31:01.135", 564 "flowEndMilliseconds": "2012-11-05T18:31:02.880", 565 "octetDeltaCount": 195383, 566 "packetDeltaCount": 88, 567 "sourceIPv6Address": "2001:db8:c:1337::2", 568 "destinationIPv6Address": "2001:db8:c:1337::3", 569 "sourceTransportPort": 80, 570 "destinationTransportPort": 32991, 571 "protocolIdentifier": "tcp", 572 "tcpControlBits": 19, 573 "flowEndReason": 3 574 } 576 Figure 2: JSON object containing sample flow 578 Author's Address 580 Brian Trammell 581 Swiss Federal Institute of Technology Zurich 582 Gloriastrasse 35 583 8092 Zurich 584 Switzerland 586 Phone: +41 44 632 70 13 587 Email: ietf@trammell.ch