Skip to main content

Architecture for IP Flow Information Export
draft-ietf-ipfix-architecture-12

Yes

(Dan Romascanu)

No Objection

(Cullen Jennings)
(David Kessens)
(Jari Arkko)
(Lisa Dusseault)
(Mark Townsley)
(Ross Callon)
(Ted Hardie)

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

Dan Romascanu Former IESG member
(was Discuss, Yes) Yes
Yes () Unknown

                            
Brian Carpenter Former IESG member
No Objection
No Objection (2006-06-30) Unknown
I'd be happier if some of the examples were for IPv6 instead of IPv4
Cullen Jennings Former IESG member
No Objection
No Objection () Unknown

                            
David Kessens Former IESG member
No Objection
No Objection () Unknown

                            
Jari Arkko Former IESG member
No Objection
No Objection () Unknown

                            
Lars Eggert Former IESG member
No Objection
No Objection (2006-06-30) Unknown
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.
Lisa Dusseault Former IESG member
No Objection
No Objection () Unknown

                            
Magnus Westerlund Former IESG member
No Objection
No Objection (2006-07-05) Unknown
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
   120}.

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.
Mark Townsley Former IESG member
No Objection
No Objection () Unknown

                            
Ross Callon Former IESG member
No Objection
No Objection () Unknown

                            
Russ Housley Former IESG member
(was Discuss) No Objection
No Objection (2006-10-25) Unknown
  I think it would help readability if Figure 5 used boxes in a
  manner similar to Figure 3.
Ted Hardie Former IESG member
No Objection
No Objection () Unknown