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,
In the text below, I explain the reason behind the second IETF LC:
During the IESG telechat, the IESG concluded that this document should be
Proposed Standard, and not Informational as initially proposed in v6.
This IETF LC should focus on the Proposed Standard changes in the
latest version.
Regards, Benoit
-------- Original Message --------
Subject: [IPFIX] Last Call: <draft-ietf-ipfix-text-adt-07.txt>
(Textual Representation of IPFIX Abstract Data Types) to Proposed
Standard
Date: Wed, 16 Jul 2014 15:24:27 -0700
From: The IESG <iesg-secretary(_at_)ietf(_dot_)org>
Reply-To: <ietf(_at_)ietf(_dot_)org>
To: IETF-Announce <ietf-announce(_at_)ietf(_dot_)org>
CC: <ipfix(_at_)ietf(_dot_)org>
The IESG has received a request from the IP Flow Information Export WG
(ipfix) to consider the following document:
- 'Textual Representation of IPFIX Abstract Data Types'
<draft-ietf-ipfix-text-adt-07.txt>
During the IESG telechat, the IESG concluded that this document should be
Proposed Standard, and not Informational as initially proposed in v6.
This IETF LC should focus on the Proposed Standard changes in the
latest version.
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf(_at_)ietf(_dot_)org mailing lists by 2014-07-30. Exceptionally, comments
may be
sent toiesg(_at_)ietf(_dot_)org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.
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.
The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-ipfix-text-adt/
IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-ipfix-text-adt/ballot/
No IPR declarations have been submitted directly on this I-D.
_______________________________________________
IPFIX mailing list
IPFIX(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ipfix
.
_______________________________________________
IPFIX mailing list
IPFIX(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ipfix