The type "octetArray" represents a finite length string of octets. The type "unsigned8" represents a non-negative integer value in the range of 0 to 255. The type "unsigned16" represents a non-negative integer value in the range of 0 to 65535. The type "unsigned32" represents a non-negative integer value in the range of 0 to 4294967295. The type "unsigned64" represents a non-negative integer value in the range of 0 to 18446744073709551615. The type "signed8" represents an integer value in the range of -128 to 127. The type "signed16" represents an integer value in the range of -32768 to 32767. The type "signed32" represents an integer value in the range of -2147483648 to 2147483647. The type "signed64" represents an integer value in the range of -9223372036854775808 to 9223372036854775807. The type "float32" corresponds to an IEEE single-precision 32-bit floating point type as defined in [IEEE.754.1985]. The type "float64" corresponds to an IEEE double-precision 64-bit floating point type as defined in [IEEE.754.1985]. The type "boolean" represents a binary value. The only allowed values are "true" and "false". The type "macAddress" represents a string of 6 octets. The type "string" represents a finite length string of valid characters from the Unicode character encoding set [ISO.10646-1.1993]. Unicode allows for ASCII [ISO.646.1991] and many other international character sets to be used. The type "dateTimeSeconds" represents a time value in units of seconds normalized to the GMT time zone. The type "dateTimeMilliseconds" represents a time value in units of milliseconds normalized to the GMT time zone. The type "dateTimeMicroseconds" represents a time value in units of microseconds normalized to the GMT time zone. The type "dateTimeNanoseconds" represents a time value in units of nanoseconds normalized to the GMT time zone. The type "ipv4Address" represents a value of an IPv4 address. The type "ipv6Address" represents a value of an IPv6 address. The type "basicList" represents a list of zero or more instances of any Information Element, primarily used for single-valued data types. Examples include a list of port numbers, a list of interface indexes, and a list of AS in a BGP AS-PATH. The type "subTemplateList" represents a list of zero or more instances of a structured data type, where the data type of each list element is the same and corresponds with a single Template Record. Examples include a structured data type composed of multiple pairs of ("MPLS label stack entry position", "MPLS label stack value"), a structured data type composed of performance metrics, and a structured data type composed of multiple pairs of IP address. The type "subTemplateMultiList" represents a list of zero or more instances of structured data types, where the data type of each list element can be different and corresponds with different Template definitions. An example is a structured data type composed of multiple access-list entries, where entries can be composed of different criteria types. The default semantic is used to note that no semantics apply to the field; it cannot be manipulated by a Collecting Process or File Reader that does not understand it a priori. A quantity value represents a discrete measured value pertaining to the record. This is distinguished from counters which represent an ongoing measured value whose "odometer" reading is captured as part of a given record. If no semantic qualifier is given, the Information Elements that have an integral data type should behave as a quantity. An integral value reporting the value of a counter. Counters are unsigned and wrap back to zero after reaching the limit of the type. For example, an unsigned64 with counter semantics will continue to increment until reaching the value of 2**64 - 1. At this point the next increment will wrap its value to zero and continue counting from zero. The semantics of a total counter is similar to the semantics of counters used in SNMP, such as Counter32 defined in RFC 2578 [RFC2578]. The only difference between total counters and counters used in SNMP is that the total counters have an initial value of 0. A total counter counts independently of the export of its value. An integral value reporting the value of a counter. Counters are unsigned and wrap back to zero after reaching the limit of the type. For example, an unsigned64 with counter semantics will continue to increment until reaching the value of 2**64 - 1. At this point the next increment will wrap its value to zero and continue counting from zero. The semantics of a delta counter is similar to the semantics of counters used in SNMP, such as Counter32 defined in RFC 2578 [RFC2578]. The only difference between delta counters and counters used in SNMP is that the delta counters have an initial value of 0. A delta counter is reset to 0 each time its value is exported. An integral value which serves as an identifier. Specifically mathematical operations on two identifiers (aside from the equality operation) are meaningless. For example, Autonomous System ID 1 * Autonomous System ID 2 is meaningless. An integral value which actually represents a set of bit fields. Logical operations are appropriate on such values, but not other mathematical operations. Flags should always be of an unsigned type. Represents an arbitrary-length sequence of zero or more structured data Information Elements, either composed of regular Information Elements or composed of data conforming to a Template Record. Structured data type semantics express the relationship among multiple list elements in a structured data Information Element. Used for Information Elements that are applicable to Flow Records only. Used for Information Elements that are applicable to option records only. Used for Information Elements that are applicable to Flow Records as well as to option records. Indicates that the Information Element definition is that the definition is current and valid. Indicates that the Information Element definition is obsolete, but it permits new/continued implementation in order to foster interoperability with older/existing implementations. Indicates that the Information Element definition is obsolete and should not be implemented and/or can be removed if previously implemented. The semantics of this Information Element. Describes how this Information Element is derived from the Flow or other information available to the observer. Identifies additional specifications which more precisely define this item or provide additional context for its use. If the Information Element is a measure of some kind, the units identify what the measure is. Some Information Elements may only be able to take on a restricted set of values which can be expressed as a range (e.g. 0 through 511 inclusive). If this is the case, the valid inclusive range should be specified. A unique and meaningful name for the Information Element. One of the types listed in section 3.1 of this document or in a future extension of the information model. The type space for attributes is constrained to facilitate implementation. The existing type space does however encompass most basic types used in modern programming languages, as well as some derived types (such as ipv4Address) which are common to this domain and useful to distinguish. The integral types may be qualified by additional semantic details. Valid values for the data type semantics are specified in section 3.2 of this document or in a future extension of the information model. A numeric identifier of the Information Element. If this identifier is used without an enterprise identifier (see [I-D.ietf-ipfix-protocol] and enterpriseId below), then it is globally unique and the list of allowed values is administered by IANA. It is used for compact identification of an Information Element when encoding Templates in the protocol. Enterprises may wish to define Information Elements without registering them with IANA, for example for enterprise-internal purposes. For such Information Elements the Information Element identifier described above is not sufficient when the Information Element is used outside the enterprise. If specifications of enterprise-specific Information Elements are made public and/or if enterprise-specific identifiers are used by the IPFIX protocol outside the enterprise, then the enterprise-specific identifier MUST be made globally unique by combining it with an enterprise identifier. Valid values for the enterpriseId are defined by IANA as SMI network management private enterprise codes. They are defined at http://www.iana.org/assignments/enterprise-numbers. This property of an Information Element indicates in which kind of records the Information Element can be used. Allowed values for this property are 'data', 'option', and 'all'. The status of the specification of this Information Element. Allowed values are 'current', 'deprecated', and 'obsolete'. to be done ...