Note: This ballot was opened for revision 07 and is now closed.
Summary: Needs a YES.
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,
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
Why not just circumvent this problem by mandating a minimum intervall
for the expiration timeout that is longer than the maximum
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.