[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[IPFIX] SCTP per-stream WGLC review
All,
The following is a review of the SCTP perstream draft for WGLC.
Serious issues (repeated inline):
It is not clear in the language of the document that it is not
intended to update 5101, though its intended status precludes this.
Additionally, there are some specifications with respect to Collecting
Processes which may break interoperability.
The Data Record Reliability Options Template does not appear to be
necessary, or at least, its purpose is unclear. As I read it the CP
can deduce all the information it provides rather easily.
General comments:
I have not consistently corrected the grammar in the document where it
does not have a significant impact on clarity (e.g. spurious
articles), though the document does need a grammar and typographic
editing pass between now and final publication.
There is one general terminology issue which should be addressed; it
appears that throughout the document the phrase "Template ID" is used
to mean "number identifying a Template" as well as "Data Records (or
Data Sets) described by (or associated with) a Template". I agree this
latter construct is really awkward, but "Template ID" is a confusing
shorthand for the concept,From ipfix-bounces at ietf.org Fri Aug 29 09:04:29 2008
Return-Path: <ipfix-bounces at ietf.org>
X-Original-To: ipfix-web-archive at optimus.ietf.org
Delivered-To: ietfarch-ipfix-web-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 6210C3A6994;
Fri, 29 Aug 2008 09:04:29 -0700 (PDT)
X-Original-To: ipfix at core3.amsl.com
Delivered-To: ipfix at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id D5E203A6A20
for <ipfix at core3.amsl.com>; Fri, 29 Aug 2008 09:04:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.785
X-Spam-Level:
X-Spam-Status: No, score=-6.785 tagged_above=-999 required=5 tests=[AWL=1.814,
BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32])
by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id L1A1KZJlRE0G for <ipfix at core3.amsl.com>;
Fri, 29 Aug 2008 09:04:25 -0700 (PDT)
Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219])
by core3.amsl.com (Postfix) with ESMTP id 3FA803A677C
for <ipfix at ietf.org>; Fri, 29 Aug 2008 09:04:24 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1])
by smtp.ee.ethz.ch (Postfix) with ESMTP id 4D813D9339
for <ipfix at ietf.org>; Fri, 29 Aug 2008 18:04:25 +0200 (MEST)
X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch
Received: from smtp.ee.ethz.ch ([127.0.0.1])
by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024)
with LMTP id IopCOvbjY-Xp for <ipfix at ietf.org>;
Fri, 29 Aug 2008 18:04:25 +0200 (MEST)
Received: from pb-10072.ethz.ch (pb-10072.ethz.ch [82.130.103.195])
(using TLSv1 with cipher AES128-SHA (128/128 bits))
(No client certificate requested) (Authenticated sender: briant)
by smtp.ee.ethz.ch (Postfix) with ESMTP id E1283D9338
for <ipfix at ietf.org>; Fri, 29 Aug 2008 18:04:24 +0200 (MEST)
Message-Id: <3B2C1602-5624-4428-A706-5CFF6C3DDE52 at tik.ee.ethz.ch>
From: Brian Trammell <trammell at tik.ee.ethz.ch>
To: IETF IPFIX Working Group <ipfix at ietf.org>
Mime-Version: 1.0 (Apple Message framework v928.1)
Date: Fri, 29 Aug 2008 18:04:24 +0200
X-Mailer: Apple Mail (2.928.1)
Subject: [IPFIX] SCTP per-stream WGLC review
X-BeenThere: ipfix at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IPFIX WG discussion list <ipfix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipfix>,
<mailto:ipfix-request at ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/ipfix>
List-Post: <mailto:ipfix at ietf.org>
List-Help: <mailto:ipfix-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipfix>,
<mailto:ipfix-request at ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ipfix-bounces at ietf.org
Errors-To: ipfix-bounces at ietf.org
All,
The following is a review of the SCTP perstream draft for WGLC.
Serious issues (repeated inline):
It is not clear in the language of the document that it is not
intended to update 5101, though its intended status precludes this.
Additionally, there are some specifications with respect to Collecting
Processes which may break interoperability.
The Data Record Reliability Options Template does not appear to be
necessary, or at least, its purpose is unclear. As I read it the CP
can deduce all the information it provides rather easily.
General comments:
I have not consistently corrected the grammar in the document where it
does not have a significant impact on clarity (e.g. spurious
articles), though the document does need a grammar and typographic
editing pass between now and final publication.
There is one general terminology issue which should be addressed; it
appears that throughout the document the phrase "Template ID" is used
to mean "number identifying a Template" as well as "Data Records (or
Data Sets) described by (or associated with) a Template". I agree this
latter construct is really awkward, but "Template ID" is a confusing
shorthand for the concept, and suggest finding a replacement and using
it consistently.
> 1. Terminology
>
> IPFIX-specific terminology used in this document is defined
> in section 2 of [RFC5101]. As in [RFC5101], these IPFIX-
> specific terms have the first letter of a word capitalized
> when used in this document.
>
> Template Reuse Delay
>
> The configurable timeout to allow the Collecting Process
> to receive and process the last Data Record using this
> Template information before which the Template Withdrawal
> Message MUST NOT be sent. [RFC5101] specifies a default
> value of 5 seconds.
The wording here is confusing. I don't know what a Template Reuse
Delay is from this text. Is this correct:
"The time after sending the last Data Set described by a given
Template the Exporting Process MUST wait before sending a Template
Withdrawal Message for the Template."
It's not a CP delay, or is it? I'm confused as to what configurability
at the CP has to do with it.
> 2. Introduction
>
> The IPFIX working group has specified a protocol to export IP
> Flow information [RFC5101]. This protocol is designed to
> export information about IP traffic Flows and related
> measurement data, where a Flow is defined by a set of key
> attributes (e.g. source and destination IP address, source
> and destination port, etc.). However, thanks to its template
> mechanism, the IPFIX protocol can export any type of
> information, as long as the relevant Information Element is
> specified in the IPFIX Information Model [RFC5102],
> registered with IANA, or specified as an enterprise-specific
> Information Element.
>
> The IPFIX protocol [RFC5101] specifies that IP traffic
> measurements for Flows are exported using a TLV (type,
> length, value) format. The information is exported using a
> Template Record that is sent once to export the {type,
> length} pairs that define the data format for the Information
> Elements in a Flow. The Data Records specify values for each
> Flow.
>
> The IPFIX protocol [RFC5101] is flexible: it foresees the
> usage
> of the multiple SCTP streams per association; it allows the
> transmission of Data Sets, Template Sets, and/or Options
> Template Sets on any stream; it offers the full or partial
> reliability export of Data Sets; it proposes the ordered or
> out-
> of-order delivery of Data Sets. However, due to bandwidth
>
>
> <Claise, et. Al> Expires January 1, 2009 [Page 5]
>
> Internet-Draft <IPFIX Export per SCTP Stream> July
> 2008
>
>
> restrictions and packet losses in the network as well as
> resource constraints on the Exporter and Collector (e.g.,
> limited buffer sizes), it is not always possible to export all
> Data Sets in a reliable way.
>
I'm going to make a few stylistic suggestions here in the
introduction, because the introduction, I think, needs to be very
clear as to what the document is, and it reads a little awkwardly to
me as it stands.
> Without delving into the details of the specifications
> described
> later on in this document, the basic idea is to export the
> Template Record and its associated Data Sets into a single
> unique SCTP stream, ideally to limit the Template ID to a
> single
> stream, while imposing in-order transmission.
Introductory construct is a little unclear. Suggest replacement of
this paragraph with:
This document specifies a method for exporting a Template Record and
its associated Data Sets in a single SCTP stream, limiting each
Template ID to a single stream if possible, and imposing in-order
transmission.
> The specification in this document offers several advantages
> such as: calculation of Data Record losses in case of
> partially-
> reliable SCTP export, immediate export of the Template
> Withdrawal Message, immediate reuse of template ID within a
> stream, reduced likelihood of losing Data Record, and the
> Collecting Process's job is easier.
Text is not parallel; there are typographic errors here as well.
Suggest replacement of this paragraph with:
This method offers several advantages over IPFIX export as specified
in [RFC5101] such as the ability to calculate Data Record losses for
PR-SCTP, immediate export of Template Withdrawal Messages, immediate
reuse of Template IDs within an SCTP stream, reduced likelihood of
Data Record loss, and reduced demands on the Collecting Process.
> 2.1. Relationship with IPFIX and PSAMP
>
> The specification in this document applies to the IPFIX
> protocol specifications [RFC5101]. However, it only applies
> to the SCTP transport protocol [RFC4960] option of the IPFIX
> protocol specifications, specifically in the case of the
> partial reliability extension [RFC3758]. All specifications
> from [RFC5101] apply unless specified otherwise in this
> document.
>
> As the Packet Sampling (PSAMP) protocol specifications
> [PSAMP-PROTO] are based on the IPFIX protocol specifications,
> the specifications in this document are also valid for the
> PSAMP protocol. Therefore, the advantages specified by this
> document also apply to PSAMP.
The document specifies a method, not a set of advantages; suggest
"Therefore, the method..."
>
> 2.2. Applicability
>
> The specifications are required in cases where we must know
> how
> many Data Records of a certain type (i.e. from a certain
> Template ID) were lost. Furthermore, they apply in cases
> where
> the Exporter can not afford to export all the Flow Records
> reliably, due to the limited resources to buffer the huge
> amount
> of flow records. Such situations may occur if Data Sets are
> generated at a higher rate at the Exporter than can be
> transferred to the Collector because of bandwidth
> limitations in
>
>
> <Claise, et. Al> Expires January 1, 2009 [Page 6]
>
> Internet-Draft <IPFIX Export per SCTP Stream> July
> 2008
>
>
> the network or slow reception at the Collector. A typically
> example is a router exporting billing records.
typical example
>
> To be more precise, the specification applicability is the
> case
> where multiple Template IDs are sent within a SCTP Transport
> Session and the calculation of the Data Record loss for a
> particular one Template ID is required. Indeed, with the
> current IPFIX specifications [RFC5101], if an IPFIX Message is
> lost (UDP or SCTP partially reliable), it is not possible to
> determine to which Template ID of the Transport Session the
> lost
> Data Records belong to.
Not in the general case, no. An EP can of course use only a single
template for all export in a given session, or use a separate
observation domain for each application. This is not the _only_ way
under the current spec to estimate loss, it's just the most SCTP
friendly, and the least hackish.
> In terms of Collector, there is backwards compatibility: the
> Collecting Process does not require any changes to support an
> Exporter that complies to the specifications in this document.
Suggest:
Exporting Processes following this specification will interoperate
with existing Collecting Processes that comply with [RFC5101]; no
changes are required at the Collecting Process to support this method.
>
>
> 2.3. Limitations
>
> To be compliant with the specifications in this document, the
> Transport Session must support multiple SCTP streams.
> Furthermore, if the SCTP Transport Session does not support
> enough streams for the increasing number of Template ID in the
> Transport Session, the addition of streams must be supported
> according to [SCTP-RESET]. Alternatively, the new Template ID
> and associated Data Records may be added to an existing stream
> at the cost of diluting the granularity of Data Records loss.
> The other alternatives, which is not practical in operational
> networks, is to restart the SCTP association with an increase
> number of streams.
A few unclear and nonstandard constructs here, and a little
terminology confusion. The discussion of alternatives to one-session-
per-stream and SCTP reset is not a limitation of the approach, it's a
workaround to limitations in certain SCTP stacks, and is a bit
detailed for an introduction I think. Suggest replacement:
This method requires multiple SCTP streams in the association between
the Exporting and Collecting Process, ideally one per Template. The
SCTP association should support the addition of streams according to
[SCTP-RESET] in order to handle the transmission of additional
Templates during the Transport Session.
> 3. IPFIX Protocol Specifications Limitations and Improvements
I think this section needs some frontmatter explaining its
organization. From the point of view of the TOC it makes sense, but
reading the document through end to end it's a little disorienting.
>
> 3.2.2. IPFIX Export per SCTP Stream Advantages
>
> By exporting each Template Record and the corresponding Data
> Records within a single stream and imposing in-order
> transmission, the Template will always arrive before the
> associated Data Records. Therefore, there is no risk that
> the Collecting Process discards Data Records while waiting
> for the Template to arrive.
>
> Furthermore, when reusing a Template ID within a stream, the
> Template Withdrawal Message will be guaranteed to arrive
> before the new definition of the Template and therefore the
> Template Record may be sent directly after the Template
> Withdrawal Message. In other words, the Template Reuse Delay
> restriction (by default, 5 seconds, as specified in [RFC5101]
> is removed for Template ID reuse within the same stream.
>
> Another advantage with the new specifications in this
> document is that the Collecting Process's job is now easier.
> Indeed, the Collecting Process doesn't have to store the Data
> Records while waiting for the Template Records, as the
> transmission order is always guaranteed. This way, extra
> reliability of the Data Records is achieved without extra
> burden on the Collecting Process.
Prefer "reduces load on the CP" to "the CP's job is now easier"; the
latter reads quite informally for a specification.
It might be nice if there were some way for a full-featured CP (i.e.
one that supports buffering of Data Sets with missing Templates) to
know whether it had to preallocate buffers for such a thing, but this
is a very minor technical point.
>
> 3.3.2. IPFIX Export per SCTP Stream Advantages
>
> By exporting each Template Record and the corresponding Data
> Records within a single stream, imposing in-order
> transmission, and limiting the Template ID to a single
> stream, the issue of ordered transmission across multiple
> streams is avoided.
>
> By exporting all corresponding Data Records within the same
> ordered stream as the Template Definition, each stream is
> independent and self-contained and the interaction between
> streams is limited to that of Options Data interactions. This
> has several advantageous consequences, including the order
> preservation that does not result in the blocking of unrelated
> data and the Collector's job simplification (as the Template
> Records are guaranteed to be delivered before the associated
> Data Records).
see previous comments about the "collector's job" language.
>
>
> 4. Specifications
>
> 4.1. Template Management
>
> This section introduces modifications compared to the Template
> Management section 8 in [RFC5101].
>
>
> <Claise, et. Al> Expires January 1, 2009 [Page 10]
>
> Internet-Draft <IPFIX Export per SCTP Stream> July
> 2008
>
>
>
> As specified in [RFC5101], Template Sets and Options Template
> Sets MUST be sent reliably. In other words, any IPFIX Message
> containing an (Options) Template Set MUST be sent reliably.
Verify that all 2119 keywords drawn from 5101 actually do restate the
point properly; as I recall there was a bit of trouble over this with
the implementation guidelines.
>
> Any Data Sets associated with a Template Record MUST be sent
> on
> the same stream on which the Template Record was sent.
The use of 2119 MUST language here implies a mandatory modification to
5101. I know this is not the case given the document's intended
status, but perhaps there should be some frontmatter in section four
scoping the 2119 keywords within this section to implementations of
the specification only.
>
> The Exporter SHOULD send a single Template and associated Data
> Sets within a single stream in order to calculate the
> potential
> Data Record loss for this Template ID.
in order to _enable_ calculation (it's the collector doing the loss
calculation, right, not the exporter?)
> However, the Exporter
> MAY group related Templates and their associated Data Sets
> within a single stream so loss statistics are calculated for
> the
> group. This may be suitable in cases where there is
> insufficient SCTP streams to send each Template on its own
> stream and/or the case where there are slight variations on a
> single Template to show that some fields were unavailable at
> the
> time of monitoring.
This last sentence is kind of confusing. What I think you mean is:
This is suitable in cases where there are only slight variations among
the templates in a group, e.g. the omission of unavailable fields for
export efficiency, and may be necessary if the SCTP association does
not support enough streams to export each Template in its own stream.
Hmm... Actually, I think the specification would be greatly improved
by the formal introduction of a "template group" concept, and the
rephrasing of the specification to cover the export of one template
_group_ per stream. Since the omission of missing fields is not only
common practice but recommended by the documents, you're often likely
to get a set of related templates. Exporting these as a group is I
think what you're really trying to do with this document, since it's
application-granularity loss you're trying to estimate, yes?
> If a SCTP stream contains a mixture of Data Records defined
> by a
> Template Record and Options Template Record(s), the Data
> Records
> defined by the Options Template Record(s) SHOULD be sent
> reliably within the same stream so that the Collector does not
> consider any loss to be associated with the Options Data.
> Indeed, if the Collector does not have the guarantee that the
> Data Records defined by the Options Template Record are sent
> reliably, the Collector can not determine whether the loss in
> that stream belongs to the Data Records defined by the
> Template
> Record, defined by the Option Template Record, or by both of
> them. By sending the Options Data reliably (which is usually
> required to interpret the Data Records correctly), any loss
> will
> be limited to the non-option Data Record and loss can still be
> calculated on a per Template basis.
>
> For each (Options) Template Record, the Exporting Process MUST
> send the Data Record Reliability Option Template using an
> Option
> Template with the following Information Elements:
>
> SCOPE: Template ID
> NOT-SCOPE: dataRecordsReliability
>
> The Data Record Reliability Option Template MUST be sent
> reliably.
>
It's a template, so it must be sent reliably. This is redundant. Or do
you mean the record described by this template?
More seriously, I don't see the point of this Option. Can't the CP
just deduce from the EP's actions whether it's sending the data for a
given template reliably or not? Also, what additional functionality
does the CP really gain by deducing this? Doesn't all the stream loss
estimation stuff still work (well, on a per-group basis, anyway)?
>
> <Claise, et. Al> Expires January 1, 2009 [Page 11]
>
> Internet-Draft <IPFIX Export per SCTP Stream> July
> 2008
>
>
> The Option Data Record SHOULD be sent before the Data Record
> that needs it so that it arrives first and is available for
> the
> Collector to use.
And I presume it should also be sent reliably?
>
>
> 4.2. New Information Element
>
> dataRecordsReliability
>
> Description:
> The Data Records reliability associated with this
> Template ID. The integer value 1 means that the Data
> Records are sent reliably, while the integer value 2
> means that the Data Records are not sent reliably.
> Abstract Data Type: boolean
> Data Type Semantics: identifier
> ElementId: xxx
> Status: current
Inconsistent. Is it an integer, or a boolean?
>
>
> 4.3. SCTP
>
> This section introduces modifications compared to the "SCTP"
> section 10.2 (and subsections) in [RFC5101]. More
> specifically
> the "Stream" section 10.2.4.3
See above about 2119 language and intended status. This frontmatter
clearly reads as if it supercedes or updates 5101, which is not the
case.
>
> PR-SCTP [RFC3758] MUST be implemented by all compliant
> implementations.
>
> All IPFIX Messages MUST be sent in order within a stream.
>
> Depending on the application requirement, the Exporting
> Process
> MAY send Data Sets with full or partial reliability.
> Unreliable
> data transfer MAY be used where the application does not
> require
> reliable transmission or the use of a retransmission queue is
> impractical due to resource restrictions at the Exporter.
>
>
> If the Exporting Process requires to export a new Template but
> there are no more free SCTP streams available, it SHOULD
> attempt
> to increase the number of outbound streams it is able to send
> to, per [SCTP-RESET]. Alternatively, the Exporting Process
> MAY
> add the Template Set and Data Records to an existing stream at
> the cost of diluting the granularity of Data Records loss.
>
>
>
>
>
> <Claise, et. Al> Expires January 1, 2009 [Page 12]
>
> Internet-Draft <IPFIX Export per SCTP Stream> July
> 2008
>
>
> 4.4. Template Withdrawal Message
>
> This section introduces Template Withdrawal Message-related
> modifications compared to the Template Management section 8 in
> [RFC5101].
As above.
>
> Templates that are not used anymore SHOULD be deleted. Before
> reusing a Template ID, the Template MUST be deleted. In order
> to delete an allocated Template, the Template is withdrawn
> through the use of a Template Withdrawal Message. The
> Template
> Withdrawal Message MUST be sent on the same stream as the
> Template Record.
Inconsistent terminology. Template deletion == withdrawal?
>
> As the Template Withdrawal Message MUST be sent reliably,
> using
> SCTP-ordered delivery per [RFC5101], and as all IPFIX Messages
> are sent in order within a stream (per the specifications in
> this document), the IPFIX Message containing the Template
> Withdrawal Message will not arrive at the Collecting Process
> before any associated and previously sent Data Record. As a
> consequence, no Data Records will be lost due to delayed
> arrival
> at the Collector.
>
> The Template ID from a withdrawn Template MAY be reused on the
> same stream immediately after the Template Withdrawal
> Message is
> sent. This case is equivalent to the use of a Template Reuse
> Delay value of 0.
>
> If the new definition of the Template ID is to be reused on a
> different stream, the Template Withdrawal Message MUST NOT be
> sent before the Template Reuse Delay.
>
> A Template Withdrawal Message to withdraw all Templates for
> the
> Observation Domain ID specified in the IPFIX Message header
> MUST
> NOT be used.
>
> Multiple Template IDs MAY be withdrawn with a single Template
> Withdrawal Message at the condition that all the Template
> IDs in
> the Template Withdrawal Message are used on the same SCTP
> stream.
>
>
> 4.5. The Collecting Process's Side
>
> This section introduces modifications to the Collection
> Process
> as compared to section 9 in [RFC5101].
Modification of Collecting Process behavior is in conflict with the
statement in the introduction that EPs using this spec interoperate
with 5101 CPs. Which is it?
>
>
> <Claise, et. Al> Expires January 1, 2009 [Page 13]
>
> Internet-Draft <IPFIX Export per SCTP Stream> July
> 2008
>
>
> The Collecting Process SHOULD listen for a new association
> request from the Exporting Process. The Exporting Process
> will
> request a number of streams to use for export: the number of
> streams SHOULD be equivalent to the number of simultaneous
> Template Records used in the association. Note that the
> Template
> Records don't include the Options Template Records.
This statement does not modify 5101 CP behavior and is superfluous.
>
> A Collecting Process SHOULD support the procedure for the
> addition of an SCTP stream [SCTP-RESET].
>
> The IPFIX protocol has a Sequence Number field in the IPFIX
> Message header that increases with the number of IPFIX Data
> Records in the IPFIX Message. A Collector may detect out-of-
> sequence, dropped, or duplicate IPFIX Messages by tracking the
> Sequence Number. As this Sequence Number is per SCTP stream,
> the loss for the Data Records sent in that stream can be
> calculated in case of partially-reliable export.
A recommendation for how to do this calculation would be nice here.
>
> If the Collecting Process receives a Template Withdrawal
> Message
> on a different stream than the one on which the Template ID is
> used, then the Collecting Process MUST reset the association
> and
> SHOULD log an error message.
This is not possible without superceding 5101 and breaking
interoperability with stock 5101 EPs. Therefore it must be removed.
Furthermore (though I know we do it all over the protocol), CP-
initiated Transport Session shutdown does not follow the general
protocol design rule of "be conservative in what you send and liberal
in what you accept". Adding a new condition where we do this would be
less than ideal. But I accept that I lost this fight a while ago. :)
>
> The following sentences from [RFC5101] are not applicable in
> this specification:
>
> "The Collecting Process normally receives Template Records
> from the Exporting Process before receiving Data Records.
> The Data Records are then decoded and stored by the
> Collector. If the Template Records have not been
> received at
> the time Data Records are received, the Collecting Process
> MAY store the Data Records for a short period of time and
> decode them after the Template Records are received."
No need to remove this. CPs may still support buffering of template-
less Data even if the EP doesn't require them to.
Regards,
Brian
_______________________________________________
IPFIX mailing list
IPFIX at ietf.org
https://www.ietf.org/mailman/listinfo/ipfix