Subject: [IPFIX] WGLC for draft-ietf-ipfix-text-adt-00.txt

From: Juergen Quittek <[email-masked]>
Date: Tue, 28 Jan 2014 08:32:28 +0000

Dear all,

This is the working group last call on
draft-ietf-ipfix-text-adt-00.txt.

The call starts today and will last until Friday Feb 14.

A URL for this Internet-Draft is:
http://tools.ietf.org/html/draft-ietf-ipfix-text-adt-00

Please read the draft.
Please send your comments to this mailing list.
Please also send a message if you are fine with the draft as it is.

Thank you,
    Juergen

---

From: Paul Aitken <[email-masked]>
Date: Tue, 28 Jan 2014 14:33:50 +0000

Dear all,

Here's a review of draft-ietf-ipfix-text-adt-00.

P.

>
>
> IPFIX Working Group                                          B. Trammell
> Internet-Draft                                                ETH Zurich
> Intended status: Informational                          January 20, 2014
> Expires: July 24, 2014
>
>
>            Textual Representation of IPFIX Abstract Data Types
>                      draft-ietf-ipfix-text-adt-00.txt
>
> Abstract
>
>     This document defines UTF-8 representations for IPFIX abstract data
>     types, to support interoperable usage of the IPFIX Information
>     Elements with protocols based on textual encodings.
>
> Status of This Memo
>
>     This Internet-Draft is submitted in full conformance with the
>     provisions of BCP 78 and BCP 79.
>
>     Internet-Drafts are working documents of the Internet Engineering
>     Task Force (IETF).  Note that other groups may also distribute
>     working documents as Internet-Drafts.  The list of current Internet-
>     Drafts is at http://datatracker.ietf.org/drafts/current/.
>
>     Internet-Drafts are draft documents valid for a maximum of six months
>     and may be updated, replaced, or obsoleted by other documents at any
>     time.  It is inappropriate to use Internet-Drafts as reference
>     material or to cite them other than as "work in progress."
>
>     This Internet-Draft will expire on July 24, 2014.
>
> 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                  Expires July 24, 2014                 [Page 1]
> 
> Internet-Draft              IPFIX Text Types                January 2014
>
>
> Table of Contents
>
>     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
>     2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
>     3.  Identifying Information Elements  . . . . . . . . . . . . . .   3
>     4.  Data Type Encodings . . . . . . . . . . . . . . . . . . . . .   3
>       4.1.  octetArray  . . . . . . . . . . . . . . . . . . . . . . .   3
>       4.2.  unsigned8, unsigned16, unsigned32, and unsigned64 . . . .   4
>       4.3.  signed8, signed16, signed32, and signed64 . . . . . . . .   4
>       4.4.  float32 and float64 . . . . . . . . . . . . . . . . . . .   5
>       4.5.  boolean . . . . . . . . . . . . . . . . . . . . . . . . .   6
>       4.6.  macAddress  . . . . . . . . . . . . . . . . . . . . . . .   6
>       4.7.  string  . . . . . . . . . . . . . . . . . . . . . . . . .   6
>       4.8.  dateTime* . . . . . . . . . . . . . . . . . . . . . . . .   7
>       4.9.  ipv4Address . . . . . . . . . . . . . . . . . . . . . . .   7
>       4.10. ipv6Address . . . . . . . . . . . . . . . . . . . . . . .   8
>       4.11. basicList, subTemplateList, and subTemplateMultiList  . .   8
>     5.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
>     6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
>     7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
>       7.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
>       7.2.  Informative References  . . . . . . . . . . . . . . . . .   9
>     Appendix A.  Example  . . . . . . . . . . . . . . . . . . . . . .   9
>     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  11
>
> 1.  Introduction
>
>     The IPFIX Information Model, as defined by the IANA IPFIX Information
>     Element Registry [iana-ipfix-assignments], provides a rich set of
>     Information Elements for description of information aboutnetwork
>     entities and network traffic data,and abstract data types for these
>     Information Elements.  The IPFIX Protocol Specification [RFC7011], in

Perhaps, though it's not limited just to networks ;-)

You're suggesting that the IANA registry is the reference for the ADTs, 
rather than 7012?
7012 isn't mentioned until section 4.

>     turn, defines a big-endian binary encoding for these abstract data
>     types suitable for use with the IPFIX Protocol.

+xref for the protocol spec?

>     However, present and future operations and management protocols and
>     applications may use textual encodings, and generic framing and
>     structure as in JSON 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 for data description for
>     such applications and protocols are application specific, and
>     therefore out of scope for this document: only Information Element
>     identification and data value representation are defined here.
>
>
>
>
> Trammell                  Expires July 24, 2014                 [Page 2]
> 
> Internet-Draft              IPFIX Text Types                January 2014
>
>
> 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.  In addition, this document
>     defines the following terminology for its own use:
>
>     Enclosing Context
>        Textual representation of IPFIX data values is applied to use the
>        IPFIX Information Model within some existing textual format (e.g.
>        XML, JSON).   This outer format is referred to as the Enclosing

I can't parse that. Should it be, "A textual representation ..." ?

>        Context within this document.  Enclosing Contexts define escaping
>        and quoting rules for represented data values.
>
> 3.  Identifying Information Elements
>
>     The IPFIX Information Element Registry [iana-ipfix-assignments]
>     defines a set of Information Elementsand  numbered by Information

- "and"

>     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
>     Element Registry to textual representations.
>
>     Instead, applications using textual representations of Information
>     ElementsSHOULD  use Information Element names to identify them; see
>     Appendix A for examples illustrating this principle.

It's a SHOULD rather than a MUST. Would the IE identifier numbers be 
equally as valid?

>
> 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
>     [RFC5234], including the Core Rules inAppendix B, to describe the
>     format of textual representations of IPFIX abstract data types.

It's unclear whether that's Appendix B of this document or of 5234.

>
> 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 readability over compactness,  the values of Information

This goal should be mentioned much earlier!

>     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, and must be disregarded by any process reading the string.
>     In ABNF:
>
>
>
> Trammell                  Expires July 24, 2014                 [Page 3]
> 
> Internet-Draft              IPFIX Text Types                January 2014
>
>
>     hex-octet = 2HEXDIGIT
>
>     octetarray = 1* (hex-octet [WSP])

There's an implicit assumption of 8-bit bytes here.

An alternative encoding of "0b [10]*" (eg, 0b10101100) might sometimes 
be useful, eg for bitflags

> 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 that the unsigned Information Element has
>     identifier semantics, and refers to a set of codepoints, either in an
>     external registry, a sub-registry, or directly in the description of
>     the Information Element, then the name or short description for that
>     codepoint MAY be used to improve readability.
>
>     Otherwise, the values of Information Elements of an unsigned integer
>     type may be represented either as unprefixed base-10 (decimal)
>     strings, or as base-16 (hexadecimal) strings prefixed by '0x'; in
>     ABNF:
>
>     unsigned = 1*DIGIT / '0x' 1*HEXDIG
>
>     Leading zeroes are allowed in either encoding, and do not signify
>     base-8 (octal) encoding.
>
>     The encoded value must be in range for the corresponding abstract
>     data type or Information Element.Out of range values should be
>     interpreted as clipped to the implicit range  for the Information

That would be another use case for the unobserved-fields draft: not 
available, insufficient data, or value is out of range.

>     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.
>
>                +------------+---------+----------------------+
>                |       type | minimum |              maximum |
>                +------------+---------+----------------------+
>                |  unsigned8 |       0 |                  255 |
>                | unsigned16 |       0 |                65536 |
>                | unsigned32 |       0 |           4294967295 |
>                | unsigned64 |       0 | 18446744073709551615 |
>                +------------+---------+----------------------+
>
>               Table 1: Ranges for unsigned abstract data types

Consider comma-ising the values to make them easier to read?

>
> 4.3.  signed8, signed16, signed32, and signed64
>
>     If the Enclosing Context defines a representation for signed
>     integers, that representation SHOULD be used.
>
>
>
>
> Trammell                  Expires July 24, 2014                 [Page 4]
> 
> Internet-Draft              IPFIX Text Types                January 2014
>
>
>     Otherwise, the values of Information Elements of signed integer types
>     should be 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 encoded value must be in range for the corresponding abstract
>     data type or Information Element.  Out of range values should 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

Are +0, 0, and -0 all valid?

>
> 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 an optionally sign-prefixed, optionally
>     base-10 exponent-suffixed, floating point decimal number.  In ABNF:
>
>     sign = "+" / "-"
>
>     exponent = 'e' 1*3DIGIT
>
>     right-decimal = '.' 0*DIGIT
>
>     mantissa = 1*DIGIT [right-decimal]
>
>     float = [sign] mantissa [exponent]
>
>
>
>
> Trammell                  Expires July 24, 2014                 [Page 5]
> 
> Internet-Draft              IPFIX Text Types                January 2014
>
>
>     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.
>
>     Minimum and maximum values for abstract data types are shown in
>     Table3below.

Typo, "3 below".

>
>                 +---------+----------------+----------------+
>                 |    type | minimum abs(x) | maximum abs(x) |
>                 +---------+----------------+----------------+
>                 | float32 |      5.877e-39 |       3.403e38 |
>                 | float64 |    1.1125e-308 |     +1.798e308 |
>                 +---------+----------------+----------------+
>
>            Table 3: Ranges for floating-point abstract data types

It's not clear how you got these values. The minimum is surely zero, and 
the encoding doesn't allow negative exponents. I agree with the maximums.

> 4.5.  boolean
>
>     If the Enclosing Context defines a representation for boolean values,
>     that representation SHOULD be used.
>
>     Otherwise, a true boolean value should be represented with the
>     literal string 1, and a false boolean value with the literal string
>     0.  In ABNF:
>
>     boolean-yes = "1"
>
>     boolean-no = "0"
>
>     boolean = boolean-yes / boolean-no

Why 1/0 rather than true/false or yes/no ?

>
> 4.6.  macAddress
>
>     MAC addresses are represented as IEEE 802 MAC-48 addresses,
>     hexadecimal bytes, most significant byte first, separated by colons.
>     In ABNF, using the hex-octet production from Section 4.1:
>
>     macaddress = hex-octet 5( ":" hex-octet )
>
> 4.7.  string
>
>     As Information Elements of the string type are simply UTF-8 encoded
>     strings, they are represented directly, subject to the escaping and
>     encoding rules of the Enclosing Context.  If the Enclosing Context
>     cannot natively represent UTF-8 characters, the escaping facility
>     provided by the Enclosing Context must be used for non-representable
>     characters.  Additionally, strings containing characters reserved in
>
>
>
> Trammell                  Expires July 24, 2014                 [Page 6]
> 
> Internet-Draft              IPFIX Text Types                January 2014
>
>
>     the Enclosing Context (e.g. markup characters, quotes) must be
>     escaped or quoted according to the rules of the Enclosing Context.
>
> 4.8.  dateTime*
>
>     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 areexplictly  in UTC as well.  Time

Typo, "explicitly".

>     zone offsets are therefore not required or supported.  Second, there
>     are four timestamp abstract data types, separated by the precision
>     which they can express.  Fractional seconds must be omitted in
>     dateTimeSeconds, expressed in milliseconds in dateTimeMilliseconds,
>     and so on.
>
>     In ABNF, taken from [RFC3339] and modified:
>
>     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       = "." 3*DIGIT
>     time-usec       = "." 6*DIGIT
>     time-nsec       = "." 9*DIGIT
>     partial-time    = time-hour ":" time-minute ":" time-second
>
>     datetimeseconds      = full-date "T" partial-time
>     datetimemilliseconds = full-date "T" partial-time "." time-msec
>     datetimemicroseconds = full-date "T" partial-time "." time-usec
>     datetimenanoseconds  = full-date "T" partial-time "." time-nsec
>
> 4.9.  ipv4Address
>
>     IP version 4 addresses are represented in dotted-quad format, most-
>     significant-byte first, as it would 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)

Note that the whitespace format here is different from all other uses in 
the document (eg, macaddress and ipv6address). For consistency it should 
be 3( "." dec-octet )

>
>
>
>
> Trammell                  Expires July 24, 2014                 [Page 7]
> 
> Internet-Draft              IPFIX Text Types                January 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:
>
>     ls32        = ( h16 ":" h16 ) / IPv4address
>                 ; least-significant 32 bits of address
>     h16         = 1*4HEXDIG
>                 ; 16 bits of address represented in hexadecimal
>                 ; zeroes to suppressed as in RFC 5952
>
>     ipv6address =                            6( h16 ":" ) ls32
>                 /                       "::" 5( h16 ":" ) ls32
>                 / [               h16 ] "::" 4( h16 ":" ) ls32
>                 / [ *1( 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
>
>     This document does not present any additional security measures
>     beyond those presented by [RFC7011].

security considerations != security measures.

The text usually reads something like, "No additional security 
considerations are introduced in this document. The same security 
considerations as for the IPFIX protocol [RFC7011] apply."

>
> 6.  IANA Considerations
>
>     This document has no considerations for IANA.
>
> 7.  References
>
> 7.1.  Normative References
>
>     [RFC3339]  Klyne, G., Ed. and C. Newman, "Date and Time on the
>                Internet: Timestamps", RFC 3339, July 2002.
>
>
>
>
> Trammell                  Expires July 24, 2014                 [Page 8]
> 
> Internet-Draft              IPFIX Text Types                January 2014
>
>
>     [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
>                Resource Identifier (URI): Generic Syntax", STD 66, RFC
>                3986, January 2005.
>
>     [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
>                Architecture", RFC 4291, February 2006.
>
>     [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
>                Specifications: ABNF", STD 68, RFC 5234, January 2008.
>
>     [RFC5952]  Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
>                Address Text Representation", RFC 5952, August 2010.
>
>     [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.
>
>     [iana-ipfix-assignments]
>                Internet Assigned Numbers Authority, , "IP Flow
>                Information Export Information Elements
>                (http://www.iana.org/assignments/ipfix/ipfix.xml)",
>                November 2012.
>
> 7.2.  Informative References
>
>     [RFC6313]  Claise, B., Dhandapani, G., Aitken, P., and S. Yates,
>                "Export of Structured Data in IP Flow Information Export
>                (IPFIX)", RFC 6313, July 2011.
>
>     [RFC7012]  Claise, B. and B. Trammell, "Information Model for IP Flow
>                Information Export (IPFIX)", RFC 7012, September 2013.
>
>     [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.
>
> 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, merely an illustration of the encodings in this
>     document.
>
>     Figure 1 shows a Template in IESpec format as defined in section 10.1
>     of [RFC7013].  A Message containing this Template and a Data Record
>
>
>
> Trammell                  Expires July 24, 2014                 [Page 9]
> 
> Internet-Draft              IPFIX Text Types                January 2014
>
>
>     is shown in Figure 2, and a corresponding JSON Object using the text
>     format defined in this document is shown in Figure 3.
>
>           flowStartMilliseconds(152)<dateTimeMilliseconds>[8]
>           flowEndMilliseconds(153)<dateTimeMilliseconds>[8]
>           octetDeltaCount(1)<unsigned64>[4]
>           packetDeltaCount(2)<unsigned64>[4]
>           sourceIPv6Address(27)<ipv4Address>[4]{key}
>           destinationIPv6Address(28)<ipv4Address>[4]{key}
>           sourceTransportPort(7)<unsigned16>[2]{key}
>           destinationTransportPort(11)<unsigned16>[2]{key}
>           protocolIdentifier(4)<unsigned8>[1]{key}
>           tcpControlBits(6)<unsigned8>[1]
>           flowEndReason(136)<unsigned8>[1]
>
>                    Figure 1: Sample flow template (IPFIX)

Perhaps, "Sample IPFIX flow template in IESpec format"? Consider 
dropping the "IPFIX", since it's almost meaningless here.

>
>               1         2         3         4         5         6
>     0 2 4 6 8 0 2 4 6 8 0 2 4 6 8 0 2 4 6 8 0 2 4 6 8 0 2 4 6 8 0 2
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    | 0x000a        | length 135    | export time 1352140263        | msg
>    | sequence 0                    | domain 1                      | hdr
>    | SetID 2       | length 52     | tid 256       | fields 11     | tmpl
>    | IE 152        | length 8      | IE 153        | length 8      | set
>    | IE 1          | length 4      | IE 2          | length 4      |
>    | IE 27         | length 16     | IE 28         | length 16     |
>    | IE 7          | length 2      | IE 11         | length 2      |
>    | IE 4          | length 1      | IE 6          | length 1      |
>    | IE 136        | length 1      | SetID 256     | length 83     | data
>    | start time                                     1352140261135  | set
>    | end time                                       1352140262880  |
>    | octets                195383  | packets                   88  |
>    | sip6                                                          |
>    |                       2001:0db8:000c:1337:0000:0000:0000:0002 |
>    | dip6                                                          |
>    |                       2001:0db8:000c:1337:0000:0000:0000:0003 |
>    | sp        80  | dp     32991  | prt 6 | tcp 19| fe 3  |
>    +-------------------------------------------------------+

The figure is 63 chars wide rather than 64; each column is 15 chars wide.
It might be clearer to draw the usual 1-bit-per-column, 32-bit-wide figure.

>                Figure 2: IPFIX message containing sample flow

Is it still an IPFIX message?
Should message be capitalised?

>
>
>
>
>
>
>
>
>
>
>
> Trammell                  Expires July 24, 2014                [Page 10]
> 
> Internet-Draft              IPFIX Text Types                January 2014
>
>
>             {
>                 "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 3: JSON object containing sample flow

Note that the quoting, and colon/comma format are JSON specific.

P.

>
> Author's Address
>
>     Brian Trammell
>     Swiss Federal Institute of Technology Zurich
>     Gloriastrasse 35
>     8092 Zurich
>     Switzerland
>
>     Phone: +41 44 632 70 13
>     Email: [email-masked]
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Trammell                  Expires July 24, 2014                [Page 11]

---

From: Andrew Feren <[email-masked]>
Date: Tue, 28 Jan 2014 10:05:17 -0500

Hi all,

> Here's a review of draft-ietf-ipfix-text-adt-00.
[ snip ]
> Why 1/0 rather than true/false or yes/no ?

Also why the departure from 1 for true and 2 for false in RFC 7011.

"
6.1.5.  boolean

   The boolean data type is specified according to the TruthValue in
   [RFC2579].  It is encoded as a single-octet integer per
   Section 6.1.1, with the value 1 for true and value 2 for false.
   Every other value is undefined."

1 and 2 aren't what I would have picked, but changing it up here only
seems to create potential confusion.

As for why not true/false, I'm all in favor of a single encoding, but we
already have IEs where 'Possible values are: { "yes", "y", 1 }, { "no",
"n", 2 } and { "unassigned", "u", 0 }.'  (As an aside does anyone know
why so many options anyways?)

-Andrew

---

From: Brian Trammell <[email-masked]>
Date: Tue, 28 Jan 2014 16:47:31 +0100

Hi Andrew, Paul,

I’ll answer this one first since it’s easy. :)

>> Why 1/0 rather than true/false or yes/no ?

Internationalization, mainly. 

> Also why the departure from 1 for true and 2 for false in RFC 7011.

Because these are just wrong. I know we inherited them from SNMP. They were wrong there too.

In a textual format, which humans might have occasion to read and write, requiring “2” to mean “false” is just _asking_ for confusion, much more so than departing from the binary encoding of IPFIX.

Cheers,

Brian

> 1 and 2 aren't what I would have picked, but changing it up here only seems to create potential confusion.
> 
> As for why not true/false, I'm all in favor of a single encoding, but we already have IEs where 'Possible values are: { "yes", "y", 1 }, { "no", "n", 2 } and { "unassigned", "u", 0 }.'  (As an aside does anyone know why so many options anyways?)
> 
> -Andrew

---

From: Paul Aitken <[email-masked]>
Date: Tue, 28 Jan 2014 16:09:35 +0000

FYI, 1 and 2 are used for MIB TruthValue.

Also 0 is often used as a "don't know", so 1/2 avoids any ambiguity.

P.

On 28/01/2014 15:05, Andrew Feren wrote:
> As for why not true/false, I'm all in favor of a single encoding, but 
> we already have IEs where 'Possible values are: { "yes", "y", 1 }, { 
> "no", "n", 2 } and { "unassigned", "u", 0 }.'  (As an aside does 
> anyone know why so many options anyways?)
>
> -Andrew

---

From: Brian Trammell <[email-masked]>
Date: Tue, 28 Jan 2014 17:27:16 +0100

hi Paul,

many thanks for the review! Will put these on the list for a post-wglc -01 revision; have snipped those I accept without comment from the following, with commentcomments inline...

On 28 Jan 2014, at 15:33, Paul Aitken <[email-masked]> wrote:
>>    Information Elements for description of information about network
>>    entities and network traffic data, and abstract data types for these

The protocol no, the information model is presently

> You're suggesting that the IANA registry is the reference for the ADTs, rather than 7012?

I am, and that’s incorrect. I’ll correct this:

The IPFIX Information Model [RFC 7012] provides a set of abstract data types for the IPFIX Information Element Registry [IANA-IPFIX], which in turn contains a rich set of...
> +xref for the protocol spec?

Hm? Already cited [RFC7011] in this sentence.

> I can't parse that. Should it be, "A textual representation ...” ?

Yes it should. (I tried to write this such that the first sentence could be a definition rather than just exposition, but wasn’t able to come up with anything that was less awkward than this.)

<snip>

>>    Elements SHOULD use Information Element names to identify them; see
> It's a SHOULD rather than a MUST. Would the IE identifier numbers be equally as valid?

Hm. Not equally valid, but not invalid (consider an application transcoding IPFIX to JSON that only had number information because some lazy exporter vendor didn’t stick 5610 data in the stream). And I didn’t want to MUST this here because I could also think of situations where a text representation handled Information Element values positionally. The point here is just to define the ADT representations in an interoperable way, not to cover every possible application therefor.

>>    [RFC5234], including the Core Rules in Appendix B, to describe the

Of 5234, will fix.
>>    Otherwise, since the goal of textual representation of Information

Indeed, will move to introduction.
> There's an implicit assumption of 8-bit bytes here.

Also in the name of the abstract data type: “octet” means group of eight bits, so I’m happy sticking with this assumption.

> An alternative encoding of "0b [10]*" (eg, 0b10101100) might sometimes be useful, eg for bitflags

Good point. Flags are usually implemented as unsigned, so we’d want to add binary there too as well.

<snap>
> Are +0, 0, and -0 all valid?

As long as they’re treated to be equal, yes.

>>    float = [sign] mantissa [exponent]

There’s an error here: exponent should be ‘e’ [sign] 1*3DIGIT (see below)
> It's not clear how you got these values. The minimum is surely zero, and the encoding doesn't allow negative exponents. I agree with the maximums.

minimum nonzero abs(x) is what’s intended here. These came from IEEE 754 (via Wikipedia, I think); this needs a cite.
> Why 1/0 rather than true/false or yes/no ?

Internationalization. See my other message for my rant “why not 1/2”. :)

<snip>
> Perhaps, "Sample IPFIX flow template in IESpec format"? Consider dropping the "IPFIX", since it's almost meaningless here.

Yep.

> The figure is 63 chars wide rather than 64; each column is 15 chars wide.

This is intentional, to get us back to 72-wide with some annotation space on the left.

See RFC 6235.

> It might be clearer to draw the usual 1-bit-per-column, 32-bit-wide figure.

Which won’t fit on a page and takes up ridiculous amounts of space for the v6 addresses.

> Should message be capitalised?

Yes, indeed.
> Note that the quoting, and colon/comma format are JSON specific.

Will do (above, in the intro text).

Thanks again! Cheers,

Brian