IP Flow Information Export (IPFIX) Implementation Guidelines
RFC 5153

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)

(Chris Newman) No Objection

(Tim Polk) No Objection

(David Ward) (was Discuss) No Objection

(Magnus Westerlund) No Objection