IP Flow Information Export (IPFIX) Implementation Guidelines
Note: This ballot was opened for revision 08 and is now closed.
(Dan Romascanu) Yes
Jari Arkko No Objection
(Ron Bonica) No Objection
(Ross Callon) No Objection
(Lars Eggert) No Objection
Comment (2007-10-27 for -)
Section 1.1., paragraph 0: > 1.1. History of IPFIX I personally feel that WG history is inappropriate for a published RFC and would hence recommend to remove Section 1.1. YMMV. Section 6.2., paragraph 12: > Note that this could become an interoperability problem, e.g. if an > Exporter re-sends Templates once per day, while a Collector expires > Templates hourly, then they may both be IPFIX-compatible, but not be > interoperable. Why not just circumvent this problem by mandating a minimum intervall for the expiration timeout that is longer than the maximum retransmission timeout? Section 6.3., paragraph 1: > TCP can be used as a transport protocol for IPFIX if one of the > endpoints has no support for SCTP, but a reliable transport is needed > and/or the network between the exporter and the collector is > susceptible to congestion. All networks are susceptible to congestion, at least unless reservations are in use for all flows. Suggest to replace "is susceptible to congestion" by "has not explicitly been provisioned for the IPFIX traffic." Section 6.3., paragraph 4: > If the available bandwidth between exporter and collector is not > sufficient or the metering process generates more data records than > the collector is capable of processing, then TCP congestion control > would cause the exporter to block. Not necessarily. The socket API has functions to query buffer occupation and non-blocking I/O lets the exporter continue to sample, even if it cannot send to the collector. Section 14.2., paragraph 10: > [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., > Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., > Zhang, L., and V. Paxson, "Stream Control Transmission > Protocol", RFC 2960, October 2000. Obsoleted by RFC 4960. Section 14.2., paragraph 13: > [RFC3309] Stone, J., Stewart, R., and D. Otis, "Stream Control > Transmission Protocol (SCTP) Checksum Change", RFC 3309, > September 2002. Obsoleted by RFC 4960.
(Russ Housley) (was Discuss) No Objection
(Cullen Jennings) No Objection
Comment (2007-10-31 for -)
When the IPFIX protocol documents came out, I had some concerns about how well implementors would be able to understand what to do. This draft nice addressed all those and I would like the think the WG and authors for actually producing it. Often drafts are promised with good intentions but somehow fail to materialize - thanks for making this one real. One nit ... I sort of doubt that SCTP save resources on router line cards. (Section 6.1, para 1)