|
Benoit, Brian, All,
4. Data Type Encodings
Each subsection of this section defines a textual encoding for the
abstract data types defined in [RFC7012].
Is 7012 the correct reference? Isn't IANA's IPFIX registry now understood to be the master reference? (ie, http://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-information-element-data-types) With a view to extensibility, this document doesn't say what to do if/when new data types are added to IANA (eg, see ietf-ipfix-mib-variable-export). eg even one line to say that they can be represented in a default or limited way, or that they cannot be represented at all - in which case, how should the representation be extended in future, if needs be? Appendix A / Figure 1: While Figure 1 in this draft initially seems identical to Figure 1 in section10.2 of 7013, there are some important differences between them: 7013: sourceIPv4Address(8)<ipv4Address>[4]{key}
destinationIPv4Address(12)<ipv4Address>[4]{key}
Figure 1: sourceIPv6Address(27)<ipv4Address>[4]{key}
destinationIPv6Address(28)<ipv4Address>[4]{key}
...
tcpControlBits(6)<unsigned8>[1]
flowEndReason(136)<unsigned8>[1]
This has been wrong since -00 : sourceIPv6Address(27)<ipv4Address>[4]{key} destinationIPv6Address(28)<ipv4Address>[4]{key} (Figure 2 shows a length of 16 for these, so presumably s/v4/v6/ and s/[4]/[16]/ in the above definitions.) And tcpControlBits: tcpControlBits(6)<unsigned8>[1] - has been revised to unsigned16 [RFC7125]. Changing this would also make Figure 2 align more neatly. Figure 3: it's not clear how the strings for the timestamp, IPv6 address, and protocol identifier fields get mapped to the corresponding dateTimeMilliseconds, ipv6address, and unsigned8 types shown in Figures 1 and 2. eg, conversion is required between "tcp" and 6, so the draft should mention that. P. On 16/07/2014 23:33, Benoit Claise wrote: Dear IPFIX WG, |