Skip to main content

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

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
    RFC Editor <rfc-editor@rfc-editor.org>, 
    ipfix mailing list <ipfix@ietf.org>, 
    ipfix chair <ipfix-chairs@tools.ietf.org>
Subject: Document Action: 'Architecture for IP Flow Information 
         Export' to Informational RFC 

The IESG has approved the following document:

- 'Architecture for IP Flow Information Export '
   <draft-ietf-ipfix-architecture-12.txt> as an Informational RFC

This document is the product of the IP Flow Information Export Working 
Group. 

The IESG contact persons are Dan Romascanu and Ron Bonica.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipfix-architecture-12.txt

Ballot Text

Technical Summary
 
This memo defines the IP Flow Information eXport (IPFIX) architecture
for the selective monitoring of IP flows, and for the export of
measured IP flow information from an IPFIX device to a collector.
 
Working Group Summary

This document is a regular WG document.  There is strong consensus
in the working group that this draft describes the IPFIX architecture
clearly, while leaving the Protocol and Information Model drafts
to specify implementation requirements (using RFC 2119 terms).
 
Protocol Quality
 
The document was thoroughly reviewed by the IPFIX WG.
Bert Wijnen performed the AD review. 

Note to RFC Editor

in Section 13.2 please replace

OLD:

RFC 3550, Julyy 2003

NEW: 

RFC 3550, July 2003

in section 10.1.2
OLD:

   The IPFIX user should not use authentication-only when sensitive or
   confidential information is being exchanged.  An IPFIX solution
   should support this option.  The authentication-only option should
   provide replay attack protection.  One way to achieve this level of
   security would be:

   o  IP Authentication Header

NEW:
   The IPFIX user should not use authentication-only when sensitive or
   confidential information is being exchanged.  An IPFIX solution
   should support this option.  The authentication-only option should
   provide replay attack protection.  Some means to achieve this level
   of security are:

   o  Encapsulating Security Payload (with a null encryption algorithm)

   o  Transport Layer Security (with a null encryption algorithm)

   o  IP Authentication Header


in Section 5.3
OLD:
                 packet header capturing
                           |
                      timestamping
                           |
                           v
                    +----->+
                    |      |
                    | sampling Si (1:1 in case of no sampling)
                    |      |
                    | filtering Fi (select all when no criteria)
                    |      |
                    +------+
                           |
                           v
                         Flows

                                 Figure 5
NEW:

              +---------------------------+
              |  packet header capturing  |
              +---------------------------+
                           |
                           v
              +---------------------------+
              |       timestamping        |
              +---------------------------+
                           |
                           v
         +---------------> +
         |                 |
         |                 v
         |    +----------------------------------------------+
         |    |   sampling Si (1:1 in case of no sampling)   |
         |    +----------------------------------------------+
         |                 |
         |                 v
         |    +----------------------------------------------+
         |    |  filtering Fi (select all when no criteria)  |
         |    +----------------------------------------------+
         |                 |
         |                 v
         +-----------------+
                           |
                           v
              +---------------------------+
              |          Flows            |
              +---------------------------+

                                 Figure 5

RFC Editor Note