Architecture for IP Flow Information Export
RFC 5470

Note: This ballot was opened for revision 12 and is now closed.

(Dan Romascanu) (was Discuss, Yes) Yes

(Jari Arkko) No Objection

(Ross Callon) No Objection

(Brian Carpenter) No Objection

Comment (2006-06-30 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
I'd be happier if some of the examples were for IPv6 instead of IPv4

(Lisa Dusseault) No Objection

Lars Eggert No Objection

Comment (2006-06-30 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
Section 2., paragraph 6:

>       An Observation Domain is the largest set of Observation Points for
>       which Flow information can be aggregated by a Metering Process.
>       For example, a router line card may be an observation domain if it
>       is composed of several interfaces, each of which is an Observation
>       Point.  Each Observation Domain presents itself to the Collecting
>       Process using an Observation Domain ID to identify the IPFIX
>       Messages it generates.  Every Observation Point is associated with
>       an Observation Domain.  It is RECOMMENDED that Observation Domain
>       IDs are also unique per IPFIX Device.

  s/RECOMMENDED/recommended/ or need to include RFC2119 boilerplate and
  cite it

Section 8.2., paragraph 2:

>    Once connected, an IPFIX Collector receives Control Information and
>    uses that information to interpret Flow Records.  The IPFIX Device
>    should set a keepalive (e.g. the keepalive timeout in the case of
>    TCP, the HEARTBEAT interval in the case of SCTP) to a sufficiently
>    low value so that it can quickly detect a Collector failure.

  It may be worth pointing out that extremely short keepalive intervals
  can incorrectly abort the connection during transient periods of
  congestion. They can also cause some level of additional network load
  during otherwise idle periods.

Section 11.1., paragraph 0:

 11.1.  Numbers used in the Protocol

  I think this section should be removed, because IPFIX-PROTO [3]
  already defines the IANA considerations for these fields.

Section 11.2., paragraph 0:

 11.2.  Numbers used in the Information Model

  Ditto, because IPFIX-INFO [2] defines IANA considerations for those.

(Ted Hardie) No Objection

(Russ Housley) (was Discuss) No Objection

Comment (2006-10-25)
No email
send info
  I think it would help readability if Figure 5 used boxes in a
  manner similar to Figure 3.

(Cullen Jennings) No Objection

(David Kessens) No Objection

(Mark Townsley) No Objection

(Magnus Westerlund) No Objection

Comment (2006-07-05 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
Reference 5 is obsolete. RFC 1889 was replaced with RFC 3550 which is STD 64. 

Section 5.2.3:

   Example: Mask/Match of the fields that define a filter.  A filter
   might be defined as {Protocol == TCP, Destination Port between 80 and

Shouldn't it be "or" between 80 and 120? Otherwise it implies that there are two destination ports in the packet that is being matched.

Section 8.1:

The WG could have considered using DCCP for the transport if one is interested in unreliable transport while still have it congestion controlled and connection oriented transport which seems to suite the application pretty well.