doc: Add RFC documents

1 files changed, 787 insertions, 0 deletions

diff --git a/doc/rfc/rfc7373.txt b/doc/rfc/rfc7373.txt
new file mode 100644
index 0000000..60b6703
--- /dev/null
+++ b/doc/rfc/rfc7373.txt
@@ -0,0 +1,787 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                       B. Trammell
+Request for Comments: 7373                                    ETH Zurich
+Category: Standards Track                                 September 2014
+ISSN: 2070-1721
+
+
+      Textual Representation of IP Flow Information Export (IPFIX)
+                          Abstract Data Types
+
+Abstract
+
+   This document defines UTF-8 representations for IP Flow Information
+   Export (IPFIX) abstract data types (ADTs) to support interoperable
+   usage of the IPFIX Information Elements with protocols based on
+   textual encodings.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7373.
+
+Copyright Notice
+
+   Copyright (c) 2014 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+
+
+
+
+Trammell                     Standards Track                    [Page 1]
+
+RFC 7373                    IPFIX Text Types              September 2014
+
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
+   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
+   3.  Identifying Information Elements  . . . . . . . . . . . . . .   3
+   4.  Data Type Encodings . . . . . . . . . . . . . . . . . . . . .   3
+     4.1.  octetArray  . . . . . . . . . . . . . . . . . . . . . . .   4
+     4.2.  unsigned8, unsigned16, unsigned32, and unsigned64 . . . .   4
+     4.3.  signed8, signed16, signed32, and signed64 . . . . . . . .   5
+     4.4.  float32 and float64 . . . . . . . . . . . . . . . . . . .   6
+     4.5.  boolean . . . . . . . . . . . . . . . . . . . . . . . . .   7
+     4.6.  macAddress  . . . . . . . . . . . . . . . . . . . . . . .   7
+     4.7.  string  . . . . . . . . . . . . . . . . . . . . . . . . .   7
+     4.8.  The dateTime ADTs . . . . . . . . . . . . . . . . . . . .   8
+     4.9.  ipv4Address . . . . . . . . . . . . . . . . . . . . . . .   8
+     4.10. ipv6Address . . . . . . . . . . . . . . . . . . . . . . .   9
+     4.11. basicList, subTemplateList, and subTemplateMultiList  . .   9
+   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
+   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
+     6.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
+     6.2.  Informative References  . . . . . . . . . . . . . . . . .  11
+   Appendix A.  Example  . . . . . . . . . . . . . . . . . . . . . .  13
+   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  14
+   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .
+
+1.  Introduction
+
+   The IP Flow Information Export (IPFIX) Information Model [RFC7012]
+   provides a set of abstract data types (ADTs) for the IANA "IPFIX
+   Information Elements" registry [IANA-IPFIX], which contains a rich
+   set of Information Elements for description of information about
+   network entities and network traffic data, and abstract data types
+   for these Information Elements.  The IPFIX Protocol Specification
+   [RFC7011], in turn, defines a big-endian binary encoding for these
+   abstract data types suitable for use with the IPFIX protocol.
+
+   However, present and future operations and management protocols and
+   applications may use textual encodings, and generic framing and
+   structure, as in JSON [RFC7159] or XML.  A definition of canonical
+   textual encodings for the IPFIX abstract data types would allow this
+   set of Information Elements to be used for such applications and for
+   these applications to interoperate with IPFIX applications at the
+   Information Element definition level.
+
+   Note that templating or other mechanisms used for data description
+   for such applications and protocols are application specific and,
+   therefore, out of scope for this document: only Information Element
+   identification and value representation are defined here.
+
+
+
+Trammell                     Standards Track                    [Page 2]
+
+RFC 7373                    IPFIX Text Types              September 2014
+
+
+   In most cases where a textual representation will be used, an
+   explicit tradeoff is made for human readability or manipulability
+   over compactness; this assumption is used in defining standard
+   representations of IPFIX ADTs.
+
+2.  Terminology
+
+   Capitalized terms defined in the IPFIX Protocol Specification
+   [RFC7011] and the IPFIX Information Model [RFC7012] are used in this
+   document as defined in those documents.  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].  In addition, this document
+   defines the following terminology for its own use:
+
+   Enclosing Context
+      A textual representation of Information Element values is applied
+      to use the IPFIX Information Model within some existing textual
+      format (e.g., XML [W3C-XML] and JSON [RFC7159]).  This outer
+      format is referred to as the Enclosing Context within this
+      document.  Enclosing Contexts define escaping and quoting rules
+      for represented values.
+
+3.  Identifying Information Elements
+
+   The "IPFIX Information Elements" registry [IANA-IPFIX] defines a set
+   of Information Elements numbered by Information Element identifiers
+   and named for human readability.  These Information Element
+   identifiers are meant for use with the IPFIX protocol and have little
+   meaning when applying the "IPFIX Information Elements" registry to
+   textual representations.
+
+   Instead, applications using textual representations of Information
+   Elements use Information Element names to identify them; see
+   Appendix A for examples illustrating this principle.
+
+4.  Data Type Encodings
+
+   Each subsection of this section defines a textual encoding for the
+   abstract data types defined in [RFC7012].  This section uses ABNF,
+   including the Core Rules in Appendix B of [RFC5234], to describe the
+   format of textual representations of IPFIX abstract data types.
+
+   If future documents update [RFC7012] to add new abstract data types
+   to the IPFIX Information Model, and those abstract data types are
+   generally useful, this document will also need to be updated in order
+   to define textual encodings for those abstract data types.
+
+
+
+
+Trammell                     Standards Track                    [Page 3]
+
+RFC 7373                    IPFIX Text Types              September 2014
+
+
+4.1.  octetArray
+
+   If the Enclosing Context defines a representation for binary objects,
+   that representation SHOULD be used.
+
+   Otherwise, since the goal of textual representation of Information
+   Elements is human readability over compactness, the values of
+   Information Elements of the octetArray data type are represented as a
+   string of pairs of hexadecimal digits, one pair per byte, in the
+   order the bytes would appear on the wire were the octetArray encoded
+   directly in IPFIX per [RFC7011].  Whitespace may occur between any
+   pair of digits to assist in human readability of the string but is
+   not necessary.  In ABNF:
+
+   hex-octet = 2HEXDIG
+
+   octetarray = hex-octet *([WSP] hex-octet)
+
+4.2.  unsigned8, unsigned16, unsigned32, and unsigned64
+
+   If the Enclosing Context defines a representation for unsigned
+   integers, that representation SHOULD be used.
+
+   In the special case where the unsigned Information Element has
+   identifier semantics and refers to a set of codepoints either in an
+   external registry, in a sub-registry, or directly in the description
+   of the Information Element, then the name or short description for
+   that codepoint as a string MAY be used to improve readability.
+
+   Otherwise, the values of Information Elements of an unsigned integer
+   type may be represented as either unprefixed base-10 (decimal)
+   strings, base-16 (hexadecimal) strings prefixed by "0x", or base-2
+   (binary) strings prefixed by "0b".  In ABNF:
+
+   unsigned = 1*DIGIT / "0x" 1*HEXDIG / "0b" 1*BIT
+
+   Leading zeroes are allowed in any representation and do not signify
+   base-8 (octal) representation.  Binary representation is intended for
+   use with Information Elements with flag semantics, but it can be used
+   in any case.
+
+   The encoded value MUST be in range for the corresponding abstract
+   data type or Information Element.  Values that are out of range are
+   interpreted as clipped to the implicit range for the Information
+   Element as defined by the abstract data type or to the explicit range
+   of the Information Element if defined.  Minimum and maximum values
+   for abstract data types are shown in Table 1 below.
+
+
+
+
+Trammell                     Standards Track                    [Page 4]
+
+RFC 7373                    IPFIX Text Types              September 2014
+
+
+              +------------+---------+----------------------+
+              |       type | minimum |              maximum |
+              +------------+---------+----------------------+
+              |  unsigned8 |       0 |                  255 |
+              | unsigned16 |       0 |                65535 |
+              | unsigned32 |       0 |           4294967295 |
+              | unsigned64 |       0 | 18446744073709551615 |
+              +------------+---------+----------------------+
+
+       Table 1: Ranges for Unsigned Abstract Data Types (in Decimal)
+
+4.3.  signed8, signed16, signed32, and signed64
+
+   If the Enclosing Context defines a representation for signed
+   integers, that representation SHOULD be used.
+
+   Otherwise, the values of Information Elements of signed integer types
+   are represented as optionally prefixed base-10 (decimal) strings.  In
+   ABNF:
+
+   sign = "+" / "-"
+
+   signed = [sign] 1*DIGIT
+
+   If the sign is omitted, it is assumed to be positive.  Leading zeroes
+   are allowed and do not signify base-8 (octal) encoding.  The
+   representation "-0" is explicitly allowed and is equal to zero.
+
+   The encoded value MUST be in range for the corresponding abstract
+   data type or Information Element.  Values that are out of range are
+   to be interpreted as clipped to the implicit range for the
+   Information Element as defined by the abstract data type or to the
+   explicit range of the Information Element if defined.  Minimum and
+   maximum values for abstract data types are shown in Table 2 below.
+
+        +----------+----------------------+----------------------+
+        |     type |              minimum |              maximum |
+        +----------+----------------------+----------------------+
+        |  signed8 |                 -128 |                 +127 |
+        | signed16 |               -32768 |               +32767 |
+        | signed32 |          -2147483648 |          +2147483647 |
+        | signed64 | -9223372036854775808 | +9223372036854775807 |
+        +----------+----------------------+----------------------+
+
+        Table 2: Ranges for Signed Abstract Data Types (in Decimal)
+
+
+
+
+
+
+Trammell                     Standards Track                    [Page 5]
+
+RFC 7373                    IPFIX Text Types              September 2014
+
+
+4.4.  float32 and float64
+
+   If the Enclosing Context defines a representation for floating-point
+   numbers, that representation SHOULD be used.
+
+   Otherwise, the values of Information Elements of float32 or float64
+   types are represented as optionally sign-prefixed, optionally base-10
+   exponent-suffixed, floating-point decimal numbers, as in
+   [IEEE.754.2008].  The special strings "NaN", "+inf", and "-inf"
+   represent "not a number", "positive infinity", and "negative
+   infinity", respectively.
+
+   In ABNF:
+
+   sign = "+" / "-"
+
+   exponent = "e" [sign] 1*3DIGIT
+
+   right-decimal = "." 1*DIGIT
+
+   mantissa = 1*DIGIT [right-decimal]
+
+   num = [sign] mantissa [exponent]
+
+   naninf = "NaN" / (sign "inf")
+
+   float = num / naninf
+
+   The expressed value is ( mantissa * 10 ^ exponent ).  If the sign is
+   omitted, it is assumed to be positive.  If the exponent is omitted,
+   it is assumed to be zero.  Leading zeroes may appear in the mantissa
+   and/or the exponent.  Values MUST be within range for single- or
+   double-precision numbers as defined in [IEEE.754.2008]; finite values
+   outside the appropriate range are to be interpreted as clamped to be
+   within the range.  Note that no more than three digits are required
+   or allowed for exponents in this encoding due to these ranges.
+
+   Note that since this representation is meant for human readability,
+   writers MAY sacrifice precision to use a more human-readable
+   representation of a given value, at the expense of the ability to
+   recover the exact bit pattern at the reader.  Therefore, decoders
+   MUST NOT assume that the represented values are exactly comparable
+   for equality.
+
+
+
+
+
+
+
+
+Trammell                     Standards Track                    [Page 6]
+
+RFC 7373                    IPFIX Text Types              September 2014
+
+
+4.5.  boolean
+
+   If the Enclosing Context defines a representation for boolean values,
+   that representation SHOULD be used.
+
+   Otherwise, a true boolean value is represented by the literal string
+   "true" and a false boolean value by the literal string "false".  In
+   ABNF:
+
+   boolean-true = "true"
+
+   boolean-false = "false"
+
+   boolean = boolean-true / boolean-false
+
+4.6.  macAddress
+
+   Media Access Control (MAC) addresses are represented as IEEE 802
+   MAC-48 addresses, hexadecimal bytes with the most significant byte
+   first, separated by colons.  In ABNF:
+
+   hex-octet = 2HEXDIG
+
+   macaddress = hex-octet 5( ":" hex-octet )
+
+4.7.  string
+
+   As Information Elements of the string type are simply Unicode strings
+   (encoded as UTF-8 when appearing in Data Sets in IPFIX Messages
+   [RFC7011]), they are represented directly, using the Unicode encoding
+   rules and quoting and escaping rules of the Enclosing Context.
+
+   If the Enclosing Context cannot natively represent Unicode
+   characters, the escaping facility provided by the Enclosing Context
+   MUST be used for nonrepresentable characters.  Additionally, strings
+   containing characters reserved in the Enclosing Context (e.g.,
+   control characters, markup characters, and quotes) MUST be escaped or
+   quoted according to the rules of the Enclosing Context.
+
+   It is presumed that the Enclosing Context has sufficient restrictions
+   on the use of Unicode to prevent the unsafe use of nonprinting and
+   control characters.  As there is no accepted solution for the
+   processing and safe display of mixed-direction strings, mixed-
+   direction strings should be avoided using this encoding.  Note also
+   that since this document presents no additional requirements for the
+   normalization of Unicode strings, care must be taken when comparing
+   strings using this encoding; direct byte-pattern comparisons are not
+   sufficient for determining whether two strings are equivalent.  See
+
+
+
+Trammell                     Standards Track                    [Page 7]
+
+RFC 7373                    IPFIX Text Types              September 2014
+
+
+   [RFC6885] and [PRECIS] for more on possible unexpected results and
+   related risks in comparing Unicode strings.
+
+4.8.  The dateTime ADTs
+
+   Timestamp abstract data types are represented generally as in
+   [RFC3339], with two important differences.  First, all IPFIX
+   timestamps are expressed in terms of UTC, so textual representations
+   of these Information Elements are explicitly in UTC as well.  Time
+   zone offsets are, therefore, not required or supported.  Second,
+   there are four timestamp abstract data types, separated by the
+   precision that they can express.  Fractional seconds are omitted in
+   dateTimeSeconds, expressed in milliseconds in dateTimeMilliseconds,
+   and so on.
+
+   In ABNF, taken from [RFC3339] and modified as follows:
+
+   date-fullyear   = 4DIGIT
+   date-month      = 2DIGIT  ; 01-12
+   date-mday       = 2DIGIT  ; 01-28, 01-29, 01-30, 01-31
+   time-hour       = 2DIGIT  ; 00-23
+   time-minute     = 2DIGIT  ; 00-59
+   time-second     = 2DIGIT  ; 00-58, 00-59, 00-60
+   time-msec       = "." 3DIGIT
+   time-usec       = "." 6DIGIT
+   time-nsec       = "." 9DIGIT
+   full-date       = date-fullyear "-" date-month "-" date-mday
+   integer-time    = time-hour ":" time-minute ":" time-second
+
+   datetimeseconds      = full-date "T" integer-time
+   datetimemilliseconds = full-date "T" integer-time "." time-msec
+   datetimemicroseconds = full-date "T" integer-time "." time-usec
+   datetimenanoseconds  = full-date "T" integer-time "." time-nsec
+
+4.9.  ipv4Address
+
+   IP version 4 addresses are represented in dotted-quad format, most
+   significant byte first, as it would be in a Uniform Resource
+   Identifier [RFC3986]; the ABNF for an IPv4 address is taken from
+   [RFC3986] and reproduced below:
+
+   dec-octet   = DIGIT                 ; 0-9
+               / %x31-39 DIGIT         ; 10-99
+               / "1" 2DIGIT            ; 100-199
+               / "2" %x30-34 DIGIT     ; 200-249
+               / "25" %x30-35          ; 250-255
+
+   ipv4address = dec-octet 3( "." dec-octet )
+
+
+
+Trammell                     Standards Track                    [Page 8]
+
+RFC 7373                    IPFIX Text Types              September 2014
+
+
+4.10.  ipv6Address
+
+   IP version 6 addresses are represented as in Section 2.2 of
+   [RFC4291], as updated by Section 4 of [RFC5952].  The ABNF for an
+   IPv6 address is taken from [RFC3986] and reproduced below, using the
+   ipv4address production from the previous section:
+
+   ls32        = ( h16 ":" h16 ) / ipv4address
+               ; least significant 32 bits of address
+   h16         = 1*4HEXDIG
+               ; 16 bits of address represented in hexadecimal
+               ; zeroes to be suppressed as in RFC 5952
+
+   ipv6address =                            6( h16 ":" ) ls32
+               /                       "::" 5( h16 ":" ) ls32
+               / [               h16 ] "::" 4( h16 ":" ) ls32
+               / [     h16 ":"   h16 ] "::" 3( h16 ":" ) ls32
+               / [ *2( h16 ":" ) h16 ] "::" 2( h16 ":" ) ls32
+               / [ *3( h16 ":" ) h16 ] "::"    h16 ":"   ls32
+               / [ *4( h16 ":" ) h16 ] "::"              ls32
+               / [ *5( h16 ":" ) h16 ] "::"              h16
+               / [ *6( h16 ":" ) h16 ] "::"
+
+4.11.  basicList, subTemplateList, and subTemplateMultiList
+
+   These abstract data types, defined for IPFIX Structured Data
+   [RFC6313], do not represent actual data types; they are instead
+   designed to provide a mechanism by which complex structure can be
+   represented in IPFIX below the template level.  It is assumed that
+   protocols using textual Information Element representation will
+   provide their own structure.  Therefore, Information Elements of
+   these data types MUST NOT be used in textual representations.
+
+5.  Security Considerations
+
+   The security considerations for the IPFIX protocol [RFC7011] apply.
+
+   Implementations of decoders of Information Element values using these
+   representations must take care to correctly handle invalid input, but
+   the encodings presented here are not special in that respect.
+
+   The encoding specified in this document, and representations that may
+   be built upon it, are specifically not intended for the storage of
+   data.  However, since storage of data in the format in which it is
+   exchanged is a very common practice, and the ubiquity of tools for
+   indexing and searching text significantly increases the ease of
+   searching and the risk of privacy-sensitive data being accidentally
+   indexed or searched, the privacy considerations in Section 11.8 of
+
+
+
+Trammell                     Standards Track                    [Page 9]
+
+RFC 7373                    IPFIX Text Types              September 2014
+
+
+   [RFC7011] are especially important to observe when storing data using
+   the encoding specified in this document that was derived from the
+   measurement of network traffic.
+
+   When using representations based on this encoding to transmit or
+   store network traffic data, consider omitting especially privacy-
+   sensitive values by not representing the columns or keys containing
+   those values, as in black-marker anonymization as discussed in
+   Section 4 of [RFC6235].  Other anonymization techniques described in
+   [RFC6235] may also be useful in these situations.
+
+   The encodings for all abstract data types other than 'string' are
+   defined in such a way as to be representable in the US-ASCII
+   character set and, therefore, should be unproblematic for all
+   Enclosing Contexts.  However, the 'string' abstract data type may be
+   vulnerable to problems with ill-formed UTF-8 strings as discussed in
+   Section 6.1.6 of [RFC7011]; see [UTF8-EXPLOIT] for background.
+
+6.  References
+
+6.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997,
+              <http://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC3339]  Klyne, G., Ed. and C. Newman, "Date and Time on the
+              Internet: Timestamps", RFC 3339, July 2002,
+              <http://www.rfc-editor.org/info/rfc3986>.
+
+   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
+              Resource Identifier (URI): Generic Syntax", STD 66, RFC
+              3986, January 2005,
+              <http://www.rfc-editor.org/info/rfc3986>.
+
+   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
+              Architecture", RFC 4291, February 2006,
+              <http://www.rfc-editor.org/info/rfc4291>.
+
+   [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
+              Specifications: ABNF", STD 68, RFC 5234, January 2008,
+              <http://www.rfc-editor.org/info/rfc5234>.
+
+   [RFC5952]  Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
+              Address Text Representation", RFC 5952, August 2010,
+              <http://www.rfc-editor.org/info/rfc5952>.
+
+
+
+
+
+Trammell                     Standards Track                   [Page 10]
+
+RFC 7373                    IPFIX Text Types              September 2014
+
+
+   [RFC7011]  Claise, B., Trammell, B., and P. Aitken, "Specification of
+              the IP Flow Information Export (IPFIX) Protocol for the
+              Exchange of Flow Information", STD 77, RFC 7011, September
+              2013, <http://www.rfc-editor.org/info/rfc7011>.
+
+6.2.  Informative References
+
+   [IANA-IPFIX]
+              IANA, "IPFIX Information Elements",
+              <http://www.iana.org/assignments/ipfix/>.
+
+   [IEEE.754.2008]
+              Institute of Electrical and Electronics Engineers, "IEEE
+              Standard for Floating-Point Arithmetic", IEEE Standard
+              754, August 2008.
+
+   [PRECIS]   Saint-Andre, P. and M. Blanchet, "PRECIS Framework:
+              Preparation and Comparison of Internationalized Strings in
+              Application Protocols", Work in Progress, draft-ietf-
+              precis-framework-18, September 2014.
+
+   [RFC6235]  Boschi, E. and B. Trammell, "IP Flow Anonymization
+              Support", RFC 6235, May 2011,
+              <http://www.rfc-editor.org/info/rfc6235>.
+
+   [RFC6313]  Claise, B., Dhandapani, G., Aitken, P., and S. Yates,
+              "Export of Structured Data in IP Flow Information Export
+              (IPFIX)", RFC 6313, July 2011,
+              <http://www.rfc-editor.org/info/rfc6313>.
+
+   [RFC6885]  Blanchet, M. and A. Sullivan, "Stringprep Revision and
+              Problem Statement for the Preparation and Comparison of
+              Internationalized Strings (PRECIS)", RFC 6885, March 2013,
+              <http://www.rfc-editor.org/info/rfc6885>.
+
+   [RFC7012]  Claise, B. and B. Trammell, "Information Model for IP Flow
+              Information Export (IPFIX)", RFC 7012, September 2013,
+              <http://www.rfc-editor.org/info/rfc7012>.
+
+   [RFC7013]  Trammell, B. and B. Claise, "Guidelines for Authors and
+              Reviewers of IP Flow Information Export (IPFIX)
+              Information Elements", BCP 184, RFC 7013, September 2013,
+              <http://www.rfc-editor.org/info/rfc7013>.
+
+   [RFC7159]  Bray, T., "The JavaScript Object Notation (JSON) Data
+              Interchange Format", RFC 7159, March 2014,
+              <http://www.rfc-editor.org/info/rfc7159>.
+
+
+
+
+Trammell                     Standards Track                   [Page 11]
+
+RFC 7373                    IPFIX Text Types              September 2014
+
+
+   [UTF8-EXPLOIT]
+              Davis, M. and M. Suignard, "Unicode Technical Report #36:
+              Unicode Security Considerations", The Unicode Consortium,
+              November 2012.
+
+   [W3C-XML]  Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and
+              F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth
+              Edition)", W3C Recommendation REC-xml, November 2008.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Trammell                     Standards Track                   [Page 12]
+
+RFC 7373                    IPFIX Text Types              September 2014
+
+
+Appendix A.  Example
+
+   In this section, we examine an IPFIX Template and a Data Record
+   defined by that Template and show how that Data Record would be
+   represented in JSON according to the specification in this document.
+   Note that this is specifically NOT a recommendation for a particular
+   representation but merely an illustration of the encodings in this
+   document; the quoting and formatting in the example are JSON
+   specific.
+
+   Figure 1 shows a Template in Information Element Specifier (IESpec)
+   format as defined in Section 10.1 of [RFC7013]; a corresponding JSON
+   object representing a record defined by this template in the text
+   format specified in this document is shown in Figure 2.
+
+         flowStartMilliseconds(152)<dateTimeMilliseconds>[8]
+         flowEndMilliseconds(153)<dateTimeMilliseconds>[8]
+         octetDeltaCount(1)<unsigned64>[4]
+         packetDeltaCount(2)<unsigned64>[4]
+         sourceIPv6Address(27)<ipv6Address>[16]{key}
+         destinationIPv6Address(28)<ipv6Address>[16]{key}
+         sourceTransportPort(7)<unsigned16>[2]{key}
+         destinationTransportPort(11)<unsigned16>[2]{key}
+         protocolIdentifier(4)<unsigned8>[1]{key}
+         tcpControlBits(6)<unsigned16>[2]
+         flowEndReason(136)<unsigned8>[1]
+
+              Figure 1: Sample Flow Template in IESpec Format
+
+           {
+               "flowStartMilliseconds": "2012-11-05T18:31:01.135",
+               "flowEndMilliseconds": "2012-11-05T18:31:02.880",
+               "octetDeltaCount": 195383,
+               "packetDeltaCount": 88,
+               "sourceIPv6Address": "2001:db8:c:1337::2",
+               "destinationIPv6Address": "2001:db8:c:1337::3",
+               "sourceTransportPort": 80,
+               "destinationTransportPort": 32991,
+               "protocolIdentifier": "tcp",
+               "tcpControlBits": 19,
+               "flowEndReason": 3
+           }
+
+               Figure 2: JSON Object Containing Sample Flow
+
+
+
+
+
+
+
+Trammell                     Standards Track                   [Page 13]
+
+RFC 7373                    IPFIX Text Types              September 2014
+
+
+Acknowledgments
+
+   Thanks to Paul Aitken, Benoit Claise, Andrew Feren, Juergen Quittek,
+   David Black, and the IESG for their reviews and comments.  Thanks to
+   Dave Thaler and Stephan Neuhaus for discussions that improved the
+   floating-point representation section.  This work is materially
+   supported by the European Union Seventh Framework Programme under
+   grant agreement 318627 mPlane.
+
+Author's Address
+
+   Brian Trammell
+   Swiss Federal Institute of Technology Zurich
+   Gloriastrasse 35
+   8092 Zurich
+   Switzerland
+
+   Phone: +41 44 632 70 13
+   EMail: ietf@trammell.ch
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Trammell                     Standards Track                   [Page 14]
+