internet-drafts | 2 Dec 19:39 2011
Picon

[IPFIX] I-D Action: draft-ietf-ipfix-protocol-rfc5101bis-00.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item
of the IP Flow Information Export Working Group of the IETF.

	Title           : Specification of the IP Flow Information eXport (IPFIX) Protocol for the Exchange of IP Traffic
Flow Information
	Author(s)       : Benoit Claise
                          Brian Trammell
	Filename        : draft-ietf-ipfix-protocol-rfc5101bis-00.txt
	Pages           : 73
	Date            : 2011-11-29

   This document specifies the IP Flow Information Export (IPFIX)
   protocol that serves for transmitting IP Traffic Flow information
   over the network.  In order to transmit IP Traffic Flow information
   from an Exporting Process to an information Collecting Process, a
   common representation of flow data and a standard means of
   communicating them is required.  This document describes how the
   IPFIX Data and Template Records are carried over a number of
   transport protocols from an IPFIX Exporting Process to an IPFIX
   Collecting Process.  This document obsoletes RFC 5101.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipfix-protocol-rfc5101bis-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipfix-protocol-rfc5101bis-00.txt
(Continue reading)

Benoit Claise | 3 Dec 15:32 2011
Picon

[IPFIX] Fwd: New Version Notification for draft-claise-export-application-info-in-ipfix-04.txt

Dear all,

Here is a new version of the draft-claise-export-application-info-in-ipfix-04.txt.
It includes the feedback received during the last IETF
- format based on the Ethertype registry
- format based on the LLC registry
- we investigated the format based on the
- we reintroduced applicationSubCategoryName, which we inadvertently removed from version 3

http://tools.ietf.org/html/draft-claise-export-application-info-in-ipfix-04

Regards, Paul, Nir, Benoit.

-------- Original Message -------- Subject: Date: From: To: CC:
New Version Notification for draft-claise-export-application-info-in-ipfix-04.txt
Sat, 03 Dec 2011 05:19:11 -0800
internet-drafts <at> ietf.org
bclaise <at> cisco.com
bclaise <at> cisco.com, paitken <at> cisco.com, nirbd <at> cisco.com


A new version of I-D, draft-claise-export-application-info-in-ipfix-04.txt has been successfully submitted by Benoit Claise and posted to the IETF repository. Filename: draft-claise-export-application-info-in-ipfix Revision: 04 Title: Export of Application Information in IPFIX Creation date: 2011-12-03 WG ID: Individual Submission Number of pages: 37 Abstract: This document specifies an extension to the IPFIX information model specified in [RFC5102] to export application information. The IETF Secretariat
_______________________________________________
IPFIX mailing list
IPFIX <at> ietf.org
https://www.ietf.org/mailman/listinfo/ipfix
Benoit Claise | 3 Dec 15:50 2011
Picon

Re: [IPFIX] Fwd: New Version Notification for draft-claise-export-application-info-in-ipfix-04.txt

On 03/12/2011 15:32, Benoit Claise wrote:
Dear all,

Here is a new version of the draft-claise-export-application-info-in-ipfix-04.txt.
It includes the feedback received during the last IETF
- format based on the Ethertype registry
- format based on the LLC registry
- we investigated the format based on the
.. the group mac address, but discovered it was not suitable to clearly identify the protocol

Regards, Benoit.
- we reintroduced applicationSubCategoryName, which we inadvertently removed from version 3

http://tools.ietf.org/html/draft-claise-export-application-info-in-ipfix-04

Regards, Paul, Nir, Benoit.

-------- Original Message -------- Subject: Date: From: To: CC:
New Version Notification for draft-claise-export-application-info-in-ipfix-04.txt
Sat, 03 Dec 2011 05:19:11 -0800
internet-drafts <at> ietf.org
bclaise <at> cisco.com
bclaise <at> cisco.com, paitken <at> cisco.com, nirbd <at> cisco.com


A new version of I-D, draft-claise-export-application-info-in-ipfix-04.txt has been successfully submitted by Benoit Claise and posted to the IETF repository. Filename: draft-claise-export-application-info-in-ipfix Revision: 04 Title: Export of Application Information in IPFIX Creation date: 2011-12-03 WG ID: Individual Submission Number of pages: 37 Abstract: This document specifies an extension to the IPFIX information model specified in [RFC5102] to export application information. The IETF Secretariat

_______________________________________________
IPFIX mailing list
IPFIX <at> ietf.org
https://www.ietf.org/mailman/listinfo/ipfix
Benoit Claise | 5 Dec 14:45 2011
Picon

Re: [IPFIX] review of draft-claise-ipfix-mediation-protocol-04

Hi Paul,

As explained during the IETF, we overlooked this email. Sorry again.
What I like about your reviews is that it's always a WG last call level of review. So very detailed. Many thanks.

See inline.
Dear Authors,

Please find a review of draft-claise-ipfix-mediation-protocol-04.

Thanks,
P.


IPFIX Working Group B. Claise Internet-Draft Cisco Systems, Inc. Intended Status: Standards Track A. Kobayashi Expires: January 7, 2012 NTT PF Lab. B. Trammell ETH Zurich July 7, 2011 Specification of the Protocol for IPFIX Mediations

s/Mediations/Mediation/
Done.


draft-claise-ipfix-mediation-protocol-04 Abstract This document specifies the IP Flow Information Export (IPFIX) protocol specific to the Mediation.

Consider "specific to Mediation."
Done.
or "for Mediation [devices].".


Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on April, 2011. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents <Claise, et. Al> Expires January 7 2012 [Page 1] Internet-Draft <Protocol for IPFIX Mediations> July 2011 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Table of Contents 1. Introduction............................................ 3 1.1. IPFIX Documents Overview........................... 4 1.2. IPFIX Mediator Documents Overview.................. 4 1.3. Relationship with IPFIX and PSAMP.................. 5 2. Terminology............................................. 6 3. Specifications.......................................... 9 3.1. Encoding of IPFIX Message Header.................. 10 3.2. Template Management............................... 11 3.2.1. Template Management Without Template Records Change........................................11 3.2.2. Template Management With New Template Records 14 3.3. Time Management................................... 18 3.4. Observation Point Management...................... 19 3.4.1. Observation Domain Management................ 21 3.5. Specific Reporting Requirements................... 22 3.5.1. The Flow Keys Options Template............... 22 3.5.2. IPFIX Protocol Options Template.............. 22 3.5.3. IPFIX Mediator Options Template.............. 23 3.6. The Collecting Process's Side..................... 24 3.7. Configuration Management.......................... 24 4. New Information Elements............................... 24 4.1. - originalExporterIPv4Address..................... 24 4.2. originalExporterIPv6Address....................... 25 4.3. originalObservationDomainId....................... 25 5. Security Considerations................................ 25 6. IANA Considerations.................................... 26 6.1. originalExporterIPv4Address....................... 26 6.2. originalExporterIPv6Address....................... 27 6.3. originalObservationDomainId....................... 27 7. References............................................. 27 <Claise, et. Al> Expires January 6, 2012 [Page 2] Internet-Draft <Protocol for IPFIX Mediations> July 2011 7.1. Normative References.............................. 27 7.2. Informative References............................ 28 8. Author's Addresses..................................... 29 9. Appendix A. Additions to XML Specification of IPFIX Information Elements...................................... 30 1. Introduction The IPFIX architectural components in [RFC5470] consist of IPFIX Devices and IPFIX Collectors communicating using the IPFIX protocol [RFC5101], which specifies how to export IP Flow information. 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 specifications in the IPFIX protocol [RFC5101] have not been defined in the context of an IPFIX Mediator receiving, aggregating, correlating, anonymizing, etc... Flow Records from the one or multiple Exporters. Indeed, the IPFIX protocol must be adapted for Intermediate Processes, as defined in the IPFIX Mediation Reference Model as specified in the Figure A of

d/the/
Done.


[IPFIX-MED-FMWK], which is based on the IPFIX Mediation Problem Statement [RFC5982]. This document specifies the IP Flow Information Export (IPFIX) protocol in the context of the implementation and deployment of IPFIX Mediators. The use of the IPFIX protocol within a Mediator -- a device which contains both as an Exporting Process and a Collecting Process -- has an

This is back to front, since a mediator collects before it exports.
Done.


impact on the technical details of the usage of the protocol. An overview of the technical problem is covered in section 6 of the [RFC5982]: loss of original exporter

Either remove "the",
Done.
or say "the IPFIX Mediation Problem Statement".


information, loss of base time information, transport sessions management, loss of Options Template Information, Template Id management, considerations for network topology, and IPFIX Mediation interpretation, and considerations for aggregation.

Remove the first "and".
Done.


<Claise, et. Al> Expires January 6, 2012 [Page 3] Internet-Draft <Protocol for IPFIX Mediations> July 2011 The specifications in this document are based on the IPFIX protocol specifications [ref] but adapted according to the IPFIX Mediation Framework [IPFIX-MED-FMWK].

Please add the missing reference.
Done.


1.1. IPFIX Documents Overview The IPFIX Protocol [RFC5101] provides network administrators with access to IP Flow information. The architecture for the export of measured IP Flow information out of an IPFIX Exporting Process to a Collecting Process is defined in the IPFIX Architecture [RFC5470], per the requirements defined in RFC 3917 [RFC3917].

While I appreciate that this is probably cut-n-pasted from another IPFIX doc, it would be better to say, "per the requirements defined in the IPFIX Requirements doc, [RFC3917]."
Done.

The IPFIX Architecture [RFC5470] specifies how IPFIX Data Records and Templates are carried via a congestion-aware transport protocol from IPFIX Exporting Processes to IPFIX Collecting Processes. IPFIX has a formal description of IPFIX Information Elements, their name, type and additional semantic information, as specified in the IPFIX Information Model [RFC5102]. The IPFIX Applicability Statement [RFC5472] describes what type of applications can use the IPFIX protocol and how they can use the information provided. It furthermore shows how the IPFIX framework relates to other architectures and frameworks. "IPFIX Mediation: Problem Statement" [RFC5982], describing the IPFIX Mediation applicability examples, along with some problems that network administrators have been facing, is the basis for the "IPFIX Mediation: Framework" [IPFIX-MED-FMWK]. This framework details the IPFIX Mediation reference model and the components of an IPFIX Mediator. 1.2. IPFIX Mediator Documents Overview The "IPFIX Mediation: Problem Statement" [RFC5982] provides an overview of the applicability of Mediators, and defines requirements for Mediators in general terms. This document is of use largely to define the problems to be solved through the deployment of IPFIX Mediators, and to provide scope to the role of Mediators within an IPFIX collection infrastructure. <Claise, et. Al> Expires January 6, 2012 [Page 4] Internet-Draft <Protocol for IPFIX Mediations> July 2011 The "IPFIX Mediation: Framework" [IPFIX-MED-FMWK] provides more architectural details of the arrangement of Intermediate Processes within a Mediator. The details of specific Intermediate Processes, when these have additional export specifications (e.g., metadata about the intermediate processing conveyed through IPFIX Options Templates), are each treated in their own document (e.g., the "IP Flow Anonymization Support" [RFC6235]). Documents specifying the operations of specific Intermediate Processes cover the operation of these Processes within the Mediator framework, and complying to the specifications given in this

"comply with"
Done.


document; they may additionally specify the operation of the process independently, outside the context of a Mediator, when this is appropriate. As of today, these documents are: 1. "IP Flow Anonymization Support", [RFC6235], which describes Anonymization techniques for IP flow data and the export of Anonymized data using the IPFIX protocol. 2. "Flow Selection Techniques" [IPFIX-MED-FLOWSEL], which described the process of selecting a subset of flows from all

"describes".
Done.


flows observed at an observation point, along with the motivations, and some specific flow selection techniques.

"motivations"... for what?
NEW:
"Flow Selection Techniques" [IPFIX-MED-FLOWSEL], which describes the process of selecting a subset of flows from all flows observed at an observation point, the flow selection motivations, and some specific flow selection techniques.
<!-- /* Font Definitions */ <at> font-face {font-family:Batang; panose-1:2 3 6 0 0 1 1 1 1 1; mso-font-alt:&#48148;&#53461;; mso-font-charset:129; mso-generic-font-family:roman; mso-font-pitch:variable; mso-font-signature:-1342176593 1775729915 48 0 524447 0;} <at> font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4; mso-font-charset:0; mso-generic-font-family:roman; mso-font-pitch:variable; mso-font-signature:-1610611985 1107304683 0 0 159 0;} <at> font-face {font-family:"\ <at> Batang"; panose-1:2 3 6 0 0 1 1 1 1 1; mso-font-charset:129; mso-generic-font-family:roman; mso-font-pitch:variable; mso-font-signature:-1342176593 1775729915 48 0 524447 0;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {mso-style-unhide:no; mso-style-qformat:yes; mso-style-parent:""; margin-top:0cm; margin-right:0cm; margin-bottom:12.0pt; margin-left:21.6pt; line-height:12.0pt; mso-line-height-rule:exactly; mso-pagination:widow-orphan; tab-stops:21.6pt 43.2pt 64.8pt 86.4pt 108.0pt 129.6pt 151.2pt 172.8pt 194.4pt 216.0pt 237.6pt 259.2pt 280.8pt 302.4pt 324.0pt 345.6pt 367.2pt 388.8pt 410.4pt 432.0pt 16.0cm 475.2pt 496.8pt; font-size:12.0pt; font-family:"Courier New"; mso-fareast-font-family:Batang;} p.RFCText, li.RFCText, div.RFCText {mso-style-name:"RFC Text"; mso-style-priority:99; mso-style-unhide:no; mso-style-link:"RFC Text Char"; margin-top:0cm; margin-right:0cm; margin-bottom:0cm; margin-left:21.6pt; margin-bottom:.0001pt; line-height:12.0pt; mso-line-height-rule:exactly; mso-pagination:widow-orphan; font-size:12.0pt; mso-bidi-font-size:10.0pt; font-family:"Courier New"; mso-fareast-font-family:"Times New Roman"; mso-bidi-font-family:"Times New Roman";} span.RFCTextChar {mso-style-name:"RFC Text Char"; mso-style-priority:99; mso-style-unhide:no; mso-style-locked:yes; mso-style-link:"RFC Text"; mso-ansi-font-size:12.0pt; font-family:"Courier New"; mso-ascii-font-family:"Courier New"; mso-fareast-font-family:"Times New Roman"; mso-hansi-font-family:"Courier New";} .MsoChpDefault {mso-style-type:export-only; mso-default-props:yes; font-size:10.0pt; mso-ansi-font-size:10.0pt; mso-bidi-font-size:10.0pt; mso-fareast-font-family:"MS Mincho";} <at> page WordSection1 {size:612.0pt 792.0pt; margin:72.0pt 72.0pt 72.0pt 72.0pt; mso-header-margin:36.0pt; mso-footer-margin:36.0pt; mso-paper-source:0;} div.WordSection1 {page:WordSection1;} -->


3. "Exporting Aggregated Flow Data using the IP Flow Information Export" [IPFIX-MED-AGGR] which describes Aggregated Flow export within the framework of IPFIX Mediators and defines an interoperable, implementation-independent method for Aggregated Flow export.
Added (to cover the next comment)

This document specifies the IP Flow Information Export (IPFIX) protocol specific to Mediation, i.e. the specifications that all Intermediate Processes type must comply to.  Some extra specifications might be required per Intermediate Process type (In which case, the Intermediate Process specific document would cover those).

<!-- /* Font Definitions */ <at> font-face {font-family:Batang; panose-1:2 3 6 0 0 1 1 1 1 1; mso-font-alt:&#48148;&#53461;; mso-font-charset:129; mso-generic-font-family:roman; mso-font-pitch:variable; mso-font-signature:-1342176593 1775729915 48 0 524447 0;} <at> font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4; mso-font-charset:0; mso-generic-font-family:roman; mso-font-pitch:variable; mso-font-signature:-1610611985 1107304683 0 0 159 0;} <at> font-face {font-family:"\ <at> Batang"; panose-1:2 3 6 0 0 1 1 1 1 1; mso-font-charset:129; mso-generic-font-family:roman; mso-font-pitch:variable; mso-font-signature:-1342176593 1775729915 48 0 524447 0;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {mso-style-unhide:no; mso-style-qformat:yes; mso-style-parent:""; margin-top:0cm; margin-right:0cm; margin-bottom:12.0pt; margin-left:21.6pt; line-height:12.0pt; mso-line-height-rule:exactly; mso-pagination:widow-orphan; tab-stops:21.6pt 43.2pt 64.8pt 86.4pt 108.0pt 129.6pt 151.2pt 172.8pt 194.4pt 216.0pt 237.6pt 259.2pt 280.8pt 302.4pt 324.0pt 345.6pt 367.2pt 388.8pt 410.4pt 432.0pt 16.0cm 475.2pt 496.8pt; font-size:12.0pt; font-family:"Courier New"; mso-fareast-font-family:Batang;} p.RFCText, li.RFCText, div.RFCText {mso-style-name:"RFC Text"; mso-style-priority:99; mso-style-unhide:no; mso-style-link:"RFC Text Char"; margin-top:0cm; margin-right:0cm; margin-bottom:0cm; margin-left:21.6pt; margin-bottom:.0001pt; line-height:12.0pt; mso-line-height-rule:exactly; mso-pagination:widow-orphan; font-size:12.0pt; mso-bidi-font-size:10.0pt; font-family:"Courier New"; mso-fareast-font-family:"Times New Roman"; mso-bidi-font-family:"Times New Roman";} span.RFCTextChar {mso-style-name:"RFC Text Char"; mso-style-priority:99; mso-style-unhide:no; mso-style-locked:yes; mso-style-link:"RFC Text"; mso-ansi-font-size:12.0pt; font-family:"Courier New"; mso-ascii-font-family:"Courier New"; mso-fareast-font-family:"Times New Roman"; mso-hansi-font-family:"Courier New";} .MsoChpDefault {mso-style-type:export-only; mso-default-props:yes; font-size:10.0pt; mso-ansi-font-size:10.0pt; mso-bidi-font-size:10.0pt; mso-fareast-font-family:"MS Mincho";} <at> page WordSection1 {size:612.0pt 792.0pt; margin:72.0pt 72.0pt 72.0pt 72.0pt; mso-header-margin:36.0pt; mso-footer-margin:36.0pt; mso-paper-source:0;} div.WordSection1 {page:WordSection1;} -->

1.3. Relationship with IPFIX and PSAMP The specification in this document applies to the IPFIX protocol specifications [RFC5101]. All specifications from [RFC5101] apply unless specified otherwise in this document. As the Packet Sampling (PSAMP) protocol specifications [RFC5476] are based on the IPFIX protocol specifications, the specifications in this document are also valid for the PSAMP protocol. Therefore, the method specified by this document also applies to PSAMP.

Having read all this, it's not clear to me where the current document fits in to the structure.

See above.

<Claise, et. Al> Expires January 6, 2012 [Page 5] Internet-Draft <Protocol for IPFIX Mediations> July 2011 2. Terminology The IPFIX-specific terms, such as Observation Domain, Flow, Flow Key, Metering Process, Exporting Process, Exporter, IPFIX Device, Collecting Process, Collector, Template, IPFIX Message, Message Header, Template Record, Data Record, Options Template Record, Set, Data Set, Information Element, and Transport Session, used in this document are defined in [RFC5101]. The PSAMP-specific terms used in this document, such as Filtering and Sampling are defined in [RFC5476]. The IPFIX Mediation terms related to the aggregation, such as the Interval, Aggregated Flow, and Aggregated Fonction are

s/Fonction/Function/
Done.


defined in [IPFIX-MED-AGGR]. The IPFIX Mediation-specific terminology used in this document is defined in "IPFIX Mediation: Problem Statement" [RFC5982], and reuse in "IPFIX Mediation: Framework" [IPFIX-MED-FMWK].

s/reuse/reused/
Done.


However, since those two documents are an informational RFC, the

"since both of those documents are informational RFCs"
Done.


definitions have been reproduced here along with additional definitions. Similarly, since the [RFC6235] is an experimental RFC, the

Either remove "the", or say "IP Flow Anonymization Support".
Done.


Anonymization Record, Anonymized Data Record, and Intermediate Anonymization Process terms, specified in [RFC6235], are also reproduced here. In this document, as in [RFC5101], [RFC5476], [IPFIX-MED-AGGR , and [RFC6235], the first letter of each IPFIX-specific and PSAMP-specific term is capitalized along with the IPFIX Mediation-specific term defined here. In this document, we call "record stream" a stream of records carrying flow- or packet- based information. The records may be encoded as IPFIX Data

This is back to front: "In this document, we call a stream of records carrying flow- or packet-based information a "record stream".

Done.

Records in any other format.

"Records, or"
Done.


The indentation of the following sections is inconsistent.
The reason is that we start the definitions, which are indented


Transport Session Information The Transport Session is specified in [RFC5101]. In SCTP, the Transport Session Information is the SCTP association. In TCP and UDP, the Transport Session Information corresponds to a 5- tuple {Exporter IP address, Collector IP address, Exporter transport port, Collector transport port, transport protocol}. Original Exporter An Original Exporter is an IPFIX Device that hosts the Observation Points where the metered IP packets are observed. <Claise, et. Al> Expires January 6, 2012 [Page 6] Internet-Draft <Protocol for IPFIX Mediations> July 2011 Original Observation Point An Observation Point of the Original Exporter(s). In the case of the Intermediate Aggregation Process on an IPFIX Mediator, the Original Observation Point can be composed of a (set of) specific exporter(s), a (set of) specific interface(s) on an Exporter, a (set of) line card(s) on an Exporter, or any combinations of these.

This sounds like a limiting definition - in which case, please use some 2119 language.
If it's just by way of example, then please say so. eg,  "can be composed of, but not limited to, ...".
Done.
Or append, "this is not an exhaustive list."

Also, you assume that the OPs are on the Exporter, which isn't necessarily correct. First, you mean "Original Exporter".
Done.
Second, the OPs are somewhere near the MP, which may be remote from the Exporter. eg, the OPs and MP are on a linecard, while the EP is on an RP.
Or with metered data stored in a file then replayed to a mediator, the OPs may be quite remote from the EP.
This Original Observation Point definition is based on the Original Exporter definition (An Original Exporter is an IPFIX Device that hosts the Observation Points where the metered IP packets are observed), so isn't it consistent?


IPFIX Mediation IPFIX Mediation is the manipulation and conversion of a record stream for subsequent export using the IPFIX protocol. The following terms are used in this document to describe the architectural entities used by IPFIX Mediation. Intermediate Process An Intermediate Process takes a record stream as its input from Collecting Processes, Metering Processes, IPFIX File Readers, other Intermediate Processes, or other record sources; performs some transformations on this stream, based

"Some" requires > 1. Consider "one or more".
Cut and paste from RFC 6183. Listed as an open issue


upon the content of each record, states maintained across multiple records, or other data sources; and passes the

So a mediator can't do random sampling?
Question: isn't it covered by "states maintained across multiple records", i.e. I want to select one random record across 100 ones.
The states would be something such as:
    total number of records the IMP has seen, modulo 100
    whether or not one has record has been selected already for the last interval


transformed record stream as its output to Exporting Processes, IPFIX File Writers, or other Intermediate Processes, in order to perform IPFIX Mediation. Typically, an

It sounds like it's passing the output to these consumers for them to perform Mediation.
I don't think think this is what you meant. Consider moving this clause to the top:
"In order to perform IPFIX Mediation, an Intermediate Process takes a record stream..."
Cut and paste from RFC 6183. Listed as an open issue


Intermediate Process is hosted by an IPFIX Mediator.

Define "IPFIX Mediator". eg, next under "IPFIX Mediation", "IPFIX Mediator: A device which performs IPFIX mediation. An IPFIX Mediator contains both a Collecting Process and an Exporting Process".
[Later] OK, you did define this... far too far down below.
Moved here.


Alternatively, an Intermediate Process may be hosted by an Original Exporter. Specific Intermediate Processes are described below. However, this is not an exhaustive list.

Please indent the following list a bit more, so it's clear where the list ends and other definitions continue.
Done.


Intermediate Conversion Process An Intermediate Conversion Process is an Intermediate Process that transforms non-IPFIX into IPFIX, or manages the relation

What about IPFIX into non-IPFIX (eg, NFv9, Nfv5) ?

"relationship"
Cut and paste from RFC 6183. Listed as an open issue


among Templates and states of incoming/outgoing Transport Sessions (or equivalent for non IPFIX protocols) in the case of transport protocol conversion (e.g., from UDP to SCTP). Intermediate Aggregation Process <Claise, et. Al> Expires January 6, 2012 [Page 7] Internet-Draft <Protocol for IPFIX Mediations> July 2011 An Intermediate Aggregation Process is an Intermediate Process that aggregates records based upon a set of Flow Keys or functions applied to fields from the record (e.g., binning and subnet aggregation). Intermediate Correlation Process An Intermediate Correlation Process is an Intermediate Process that adds information to records, noting correlations among them, or generates new records with correlated data from multiple records (e.g., the production of bidirectional flow records from unidirectional flow records). Intermediate Selection Process An Intermediate Selection Process is an Intermediate Process that selects records from a sequence based upon criteria-

What is "a sequence" ?
Listed as an open issue


evaluated record values and passes only those records that match the criteria (e.g., Filtering only records from a given network to a given Collector). Intermediate Anonymization Process An Intermediate Anonymization Process is an Intermediate Process that transforms records in order to anonymize them, to protect the identity of the entities described by the records (e.g., by applying prefix-preserving pseudonymization of IP addresses).

Consider giving a reference here.
Listed as an open issue


IPFIX Mediator An IPFIX Mediator is an IPFIX Device that provides IPFIX Mediation by receiving a record stream from some data sources,

"Some" is > 1. "One or more" seems sufficient.
Listed as an open issue


hosting one or more Intermediate Processes to transform that stream, and exporting the transformed record stream into IPFIX

s/into/in/
Listed as an open issue


Messages via an Exporting Process. In the common case, an

Can't it write to a file too?
Listed as an open issue


IPFIX Mediator receives a record stream from a Collecting Process, but it could also receive a record stream from data sources not encoded using IPFIX, e.g., in the case of conversion from the NetFlow V9 protocol [RFC3954] to IPFIX protocol.

Great. Say this stuff WAY up at the top.
Moved just after the Intermediate Process


Template Mapping A mapping from Template Records and/or Options Template Records received by a Mediator to Template Records and/or Options Template Records sent by that IPFIX Mediator. Each <Claise, et. Al> Expires January 6, 2012 [Page 8] Internet-Draft <Protocol for IPFIX Mediations> July 2011 entry in a Template Mapping is scoped by incoming or outgoing Transport Session and Observation Domain, as with Templates and Options Templates in the IPFIX Protocol. Anonymization Record A record, defined by the Anonymization Options Template in section Section 6.1, that defines the properties of the

Oops.
Done.


Anonymization applied to a single Information Element within a single Template or Options Template. Anonymized Data Record A Data Record within a Data Set containing at least one Information Element with Anonymized values. The Information Element(s) within the Template or Options Template describing this Data Record SHOULD have a corresponding Anonymization Record. 3. Specifications This section describes the IPFIX specifications for Mediation: more specifically, specifications for generic Intermediate Processes. Possible specific Intermediate Processes are: Intermediate Conversion Process, Intermediate Aggregation Process, Intermediate Correlation Process, Intermediate Selection Process, Intermediate Anonymization Process.

Is this a definitive and exhaustive list? Earlier you said it wasn't.
We wrote: "Possible specific Intermediate Processes are:"
Do you need something else?


For a specific Intermediate Process, the specifications in the following reference MUST be followed, on the top of the specifications in this document:

"references".

Remove "the".
Done


- For the Intermediate Aggregation Process, the specifications in [IPFIX-MED-AGGR] MUST be followed. - For the Intermediate Selection Process, the specifications in [IPFIX-MED-FLOWSEL] MUST be followed. - For the Intermediate Anonymization Process, the specifications in [RFC6235] should be considered as guidelines as [RFC6235] is an experimental RFC. Note that no specific document deals with the Intermediate Conversion Process at the time of this publication.

Then where should this be specified?
Question: In a new document (which is not part of the current charter). Do we need to mention that?


These new specifications, which are more specific compared to

s/compared to/than/
done


[RFC5101], are described with the key words described in [RFC2119]. <Claise, et. Al> Expires January 6, 2012 [Page 9] Internet-Draft <Protocol for IPFIX Mediations> July 2011 3.1. Encoding of IPFIX Message Header The format of the IPFIX Message Header is shown in Figure A. Note that the format is similar to the IPFIX Message in [RFC5101], but some field definitions (for the example, the Export Time) have been updated in the context of the IPFIX Mediator. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version Number | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Export Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Observation Domain ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure A: IPFIX Message Header format Message Header Field Descriptions Version Version of Flow Record format exported in this message. The value of this field is 0x000a for the current version, incrementing by one the version used in the NetFlow services export version 9 [RFC3954]. Length Total length of the IPFIX Message, measured in octets, including Message Header and Set(s). Export Time Time in seconds since 0000 UTC Jan 1st 1970, at which the IPFIX Message Header leaves the IPFIX Mediator.

We're leave a legacy year-2106 problem :-(
Solved


Sequence Number <Claise, et. Al> Expires January 6, 2012 [Page 10] Internet-Draft <Protocol for IPFIX Mediations> July 2011 Incremental sequence counter modulo 2^32 of all IPFIX Data Records sent on this PR-SCTP stream from the

Where did you say we're using pr-SCTP?
If I'm not, then this definition doesn't apply?
This is a cut/paste from RFC5101.


current Observation Domain by the Exporting Process. Check the specific meaning of this field in the sub- sections of section 10 when UDP or TCP is selected as

You don't have a section 10. You mean, "section 10 of [RFC5101]".
Yes and no

I get the feeling I'm the first to actually read this :-(

This would refer to RFC5101, except that now we have to refer to RFC5101bis.
So I put a RFC's editor note as we have multiple evolving documents
[Later] Yes, very much so.
Btw, we really appreciate your thorough review.


the transport protocol. This value SHOULD be used by the Collecting Process to identify whether any IPFIX Data Records have been missed. Template and Options Template Records do not increase the Sequence Number. Observation Domain ID A 32-bit identifier of the Observation Domain that is locally unique to the Exporting Process. The Exporting Process uses the Observation Domain ID to uniquely identify to the Collecting Process the Observation Domain that metered the Flows. It is RECOMMENDED that this identifier is also unique per IPFIX Device. Collecting Processes SHOULD use the Transport Session and the Observation Domain ID field to separate different export streams originating from the same Exporting Process. The Observation Domain ID SHOULD be 0 when no specific Observation Domain ID is relevant for the entire IPFIX Message. For example, when exporting the Exporting Process Statistics, or in case of hierarchy of Collector when aggregated Data Records are exported. Note: the Observation Domain Management is discussed in section 3.4.1. 3.2. Template Management 3.2.1. Template Management Without Template Records Change The first case is a situation where the IPFIX Mediator doesn't modify the (Options) Template Record(s) content. A typical example is an Intermediate Selection Process acting as distributor, which collects Flow Records from one or multiple

s/multiple/more/
Done.


Exporters, and based on the Information Elements content, redirects the Flow Records to the appropriate Collector. This example is a typical case of a single network operation center managing multiple universities: an unique IPFIX Collector collects all Flow Records for the common infrastructure, but might be re-exporting specific university Flow Records to the responsible system administrator. <Claise, et. Al> Expires January 6, 2012 [Page 11] Internet-Draft <Protocol for IPFIX Mediations> July 2011 As specified in [RFC5101], the Template IDs are unique per Exporter, per Transport Session, and per Observation Domain. As there is no guarantee that, for similar Template Records, the Template IDs received on the incoming Transport Session and exported to the outgoing Transport Session would be same, the IPFIX Mediator MUST maintain a Template Mapping composed of similar received and exported (Options) Template Records:

s/similar/related/
done.


- for each received (Options) Template Record: Template Record Flow Keys and non Flow Keys, Template ID, Observation Domain Id, and Transport Session Information - for each exported (Options) Template Record: Template Record Flow Keys and non Flow Keys, Template ID, Collector, Observation Domain Id, and Transport Session Information If an IPFIX Mediator receives an IPFIX Withdrawal Message for a (Options) Template Record that is not used anymore in any outgoing Transport Sessions, the IPFIX Mediator SHOULD export the appropriate IPFIX Withdrawal Message(s) on the outgoing Transport Session, and remove the corresponding entry in the Template Mapping.

- assuming it's a 1:1 mapping. As an optimisation, the mediator could resolve identical incoming templates (which may differ in their template ID, observation domain, and perhaps in the order of their fields) into a single outgoing template in an n:1 mapping. i.e. the basic information content is the same. I hope you mention this somewhere in the draft. e.g., in figure C below, templates A and B may be identical. With the same software version and configuration on multiple boxes, this is a likely real-world scenario.
Good catch.
OLD:
If an IPFIX Mediator receives an IPFIX Withdrawal Message for a (Options) Template Record that is not used anymore in any outgoing Transport Sessions, the IPFIX Mediator SHOULD export the appropriate IPFIX Withdrawal Message(s) on the outgoing Transport Session, and remove the corresponding entry in the Template Mapping. NEW
If an IPFIX Mediator receives an IPFIX Withdrawal Message for a (Options) Template Record that is not used anymore in any other Template Mappings, the IPFIX Mediator SHOULD export the appropriate IPFIX Withdrawal Message(s) on the outgoing Transport Session, and remove the corresponding entry in the Template Mapping.
<!-- /* Font Definitions */ <at> font-face {font-family:Batang; panose-1:2 3 6 0 0 1 1 1 1 1; mso-font-alt:&#48148;&#53461;; mso-font-charset:129; mso-generic-font-family:roman; mso-font-pitch:variable; mso-font-signature:-1342176593 1775729915 48 0 524447 0;} <at> font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4; mso-font-charset:0; mso-generic-font-family:roman; mso-font-pitch:variable; mso-font-signature:-1610611985 1107304683 0 0 159 0;} <at> font-face {font-family:"\ <at> Batang"; panose-1:2 3 6 0 0 1 1 1 1 1; mso-font-charset:129; mso-generic-font-family:roman; mso-font-pitch:variable; mso-font-signature:-1342176593 1775729915 48 0 524447 0;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {mso-style-unhide:no; mso-style-qformat:yes; mso-style-parent:""; margin-top:0cm; margin-right:0cm; margin-bottom:12.0pt; margin-left:21.6pt; line-height:12.0pt; mso-line-height-rule:exactly; mso-pagination:widow-orphan; tab-stops:21.6pt 43.2pt 64.8pt 86.4pt 108.0pt 129.6pt 151.2pt 172.8pt 194.4pt 216.0pt 237.6pt 259.2pt 280.8pt 302.4pt 324.0pt 345.6pt 367.2pt 388.8pt 410.4pt 432.0pt 16.0cm 475.2pt 496.8pt; font-size:12.0pt; font-family:"Courier New"; mso-fareast-font-family:Batang;} p.RFCText, li.RFCText, div.RFCText {mso-style-name:"RFC Text"; mso-style-priority:99; mso-style-unhide:no; mso-style-link:"RFC Text Char"; margin-top:0cm; margin-right:0cm; margin-bottom:0cm; margin-left:21.6pt; margin-bottom:.0001pt; line-height:12.0pt; mso-line-height-rule:exactly; mso-pagination:widow-orphan; font-size:12.0pt; mso-bidi-font-size:10.0pt; font-family:"Courier New"; mso-fareast-font-family:"Times New Roman"; mso-bidi-font-family:"Times New Roman";} span.RFCTextChar {mso-style-name:"RFC Text Char"; mso-style-priority:99; mso-style-unhide:no; mso-style-locked:yes; mso-style-link:"RFC Text"; mso-ansi-font-size:12.0pt; font-family:"Courier New"; mso-ascii-font-family:"Courier New"; mso-fareast-font-family:"Times New Roman"; mso-hansi-font-family:"Courier New";} .MsoChpDefault {mso-style-type:export-only; mso-default-props:yes; font-size:10.0pt; mso-ansi-font-size:10.0pt; mso-bidi-font-size:10.0pt; mso-fareast-font-family:"MS Mincho";} <at> page WordSection1 {size:612.0pt 792.0pt; margin:72.0pt 72.0pt 72.0pt 72.0pt; mso-header-margin:36.0pt; mso-footer-margin:36.0pt; mso-paper-source:0;} div.WordSection1 {page:WordSection1;} -->


In this case, the TWM should cause the mediator to remove the received (Options) Template Record information, and decrement the exported (Options) Template Record refcount by 1 but only delete it if it's no longer used by anyone.
Yes. I believe it's now covered by "any other Template Mappings"


If a (Options) Template Record is not used anymore in an outgoing Transport Session, it MUST be withdrawn with an IPFIX Template Withdrawal Message on that specific outgoing Transport Session, and its entry MUST be removed from the Template Mapping. If an incoming or outgoing Transport Session is gracefully shutdown or reset, the (Options) Template Records corresponding to that Transport Session MUST be removed from the Template Mapping.

There's a rather sudden change here. Link the two sections with "For example, Figure B ..."
Done.

Figure B displays an example of an Intermediate Selection Process, re-distributing Data Records to Collectors on the basis

The figure's caption says, "Intermediate Aggregation Process Example". Which is it, selection or aggregation?
Intermediate Selection Process. Corrected. <!-- /* Font Definitions */ <at> font-face {font-family:Batang; panose-1:2 3 6 0 0 1 1 1 1 1; mso-font-alt:&#48148;&#53461;; mso-font-charset:129; mso-generic-font-family:roman; mso-font-pitch:variable; mso-font-signature:-1342176593 1775729915 48 0 524447 0;} <at> font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4; mso-font-charset:0; mso-generic-font-family:roman; mso-font-pitch:variable; mso-font-signature:-1610611985 1107304683 0 0 159 0;} <at> font-face {font-family:"\ <at> Batang"; panose-1:2 3 6 0 0 1 1 1 1 1; mso-font-charset:129; mso-generic-font-family:roman; mso-font-pitch:variable; mso-font-signature:-1342176593 1775729915 48 0 524447 0;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {mso-style-unhide:no; mso-style-qformat:yes; mso-style-parent:""; margin-top:0cm; margin-right:0cm; margin-bottom:12.0pt; margin-left:21.6pt; line-height:12.0pt; mso-line-height-rule:exactly; mso-pagination:widow-orphan; tab-stops:21.6pt 43.2pt 64.8pt 86.4pt 108.0pt 129.6pt 151.2pt 172.8pt 194.4pt 216.0pt 237.6pt 259.2pt 280.8pt 302.4pt 324.0pt 345.6pt 367.2pt 388.8pt 410.4pt 432.0pt 16.0cm 475.2pt 496.8pt; font-size:12.0pt; font-family:"Courier New"; mso-fareast-font-family:Batang;} .MsoChpDefault {mso-style-type:export-only; mso-default-props:yes; font-size:10.0pt; mso-ansi-font-size:10.0pt; mso-bidi-font-size:10.0pt; mso-fareast-font-family:"MS Mincho";} <at> page WordSection1 {size:612.0pt 792.0pt; margin:72.0pt 72.0pt 72.0pt 72.0pt; mso-header-margin:36.0pt; mso-footer-margin:36.0pt; mso-paper-source:0;} div.WordSection1 {page:WordSection1;} -->


of the customer networks, i.e. the Route Distinguisher (RD). In

d/the/
Done.


this example, the Template Record received from the Exporter#1 is reused towards the Collector#1, Collector#2, and Collector#3.

d/the/
Done.


Templ. .---------. ID 256 | | .---->|Collector|<==>Customer | |#1 | #A | | | RD=100:1 '---------' .---------.Templ. .---------. | | |Id | |----' .---------. <Claise, et. Al> Expires January 6, 2012 [Page 12] Internet-Draft <Protocol for IPFIX Mediations> July 2011 | |258 | | RD=100:2 | | |IPFIX |------->|IPFIX |--------->|Collector|<==>Customer |Exporter | |Mediator | Templ. |#2 | #B |#1 | | | ID 257 | | | | | |----. '---------' '---------' '---------' | RD=100:3 Templ.| .---------. ID | | | 257 '---->|Collector|<==>Customer |#3 | #C | | '---------' Figure B: Intermediate Aggregation Process Example

Introduce the following tables. Presumably, "The following table shows the Template Mapping for the system shown in Figure B."
Done.


Template Entry A: Incoming Transport Session Information (from Exporter#1): Source IP: <Exporter#1 export IP address> Destination IP: <IPFIX Mediator IP address> Protocol: SCTP Source Port: <source port> Destination Port: 4739 (IPFIX) Observation Domain Id: <Observation Domain ID> Template Id: 258 Flow Keys: <series of Flow Keys> Non Flow Keys: <series of non Flow Keys>

Would it be clearer to write example values in the Figure?
I've not been able to find without overloading the picture.


Template Entry B: Outgoing Transport Session Information (to Collector#1): Source IP: <IPFIX Mediator IP address> Destination IP: <IPFIX Collector#1 IP address> Protocol: SCTP Source Port: <source port> Destination Port: 4739 (IPFIX) Observation Domain Id: <Observation Domain ID> Template Id: 256 Flow Keys: <series of Flow Keys> Non Flow Keys: <series of non Flow Keys> Template Entry C: Outgoing Transport Session Information (to Collector#2): Source IP: <IPFIX Mediator IP address> Destination IP: <IPFIX Collector#2 IP address> Protocol: SCTP Source Port: <source port> <Claise, et. Al> Expires January 6, 2012 [Page 13] Internet-Draft <Protocol for IPFIX Mediations> July 2011 Destination Port: 4739 (IPFIX) Observation Domain Id: <Observation Domain ID> Template Id: 257 Flow Keys: <series of Flow Keys> Non Flow Keys: <series of non Flow Keys> Template Entry D: Outgoing Transport Session Information (to Collector#3): Source IP: <IPFIX Mediator IP address> Destination IP: <IPFIX Collector#3 IP address> Protocol: SCTP Source Port: <source port> Destination Port: 4739 (IPFIX) Observation Domain Id: <Observation Domain ID> Template Id: 257 Flow Keys: <series of Flow Keys> Non Flow Keys: <series of non Flow Keys> The Template Mapping corresponding to the figure B can be

d/the/
Done.


displayed as: Template Entry A <----> Template Entry B Template Entry A <----> Template Entry C Template Entry A <----> Template Entry D

To be picky, this looks like three instances of Template Entry A. How about:

+--> Template Entry B | Template Entry A <--+--> Template Entry C | +--> Template Entry D
The issue is that we treat the easy case first. So I added.

Alternatively, the Template Mapping may be optimized as:

 

                             +--> Template Entry B

                             |

       Template Entry A   <--+--> Template Entry C

                             |

                             +--> Template Entry D

<!-- /* Font Definitions */ <at> font-face {font-family:Batang; panose-1:2 3 6 0 0 1 1 1 1 1; mso-font-alt:&#48148;&#53461;; mso-font-charset:129; mso-generic-font-family:roman; mso-font-pitch:variable; mso-font-signature:-1342176593 1775729915 48 0 524447 0;} <at> font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4; mso-font-charset:0; mso-generic-font-family:roman; mso-font-pitch:variable; mso-font-signature:-1610611985 1107304683 0 0 159 0;} <at> font-face {font-family:"\ <at> Batang"; panose-1:2 3 6 0 0 1 1 1 1 1; mso-font-charset:129; mso-generic-font-family:roman; mso-font-pitch:variable; mso-font-signature:-1342176593 1775729915 48 0 524447 0;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {mso-style-unhide:no; mso-style-qformat:yes; mso-style-parent:""; margin-top:0cm; margin-right:0cm; margin-bottom:12.0pt; margin-left:21.6pt; line-height:12.0pt; mso-line-height-rule:exactly; mso-pagination:widow-orphan; tab-stops:21.6pt 43.2pt 64.8pt 86.4pt 108.0pt 129.6pt 151.2pt 172.8pt 194.4pt 216.0pt 237.6pt 259.2pt 280.8pt 302.4pt 324.0pt 345.6pt 367.2pt 388.8pt 410.4pt 432.0pt 16.0cm 475.2pt 496.8pt; font-size:12.0pt; font-family:"Courier New"; mso-fareast-font-family:Batang;} p.RFCText, li.RFCText, div.RFCText {mso-style-name:"RFC Text"; mso-style-priority:99; mso-style-unhide:no; mso-style-link:"RFC Text Char"; margin-top:0cm; margin-right:0cm; margin-bottom:0cm; margin-left:21.6pt; margin-bottom:.0001pt; line-height:12.0pt; mso-line-height-rule:exactly; mso-pagination:widow-orphan; font-size:12.0pt; mso-bidi-font-size:10.0pt; font-family:"Courier New"; mso-fareast-font-family:"Times New Roman"; mso-bidi-font-family:"Times New Roman";} span.RFCTextChar {mso-style-name:"RFC Text Char"; mso-style-priority:99; mso-style-unhide:no; mso-style-locked:yes; mso-style-link:"RFC Text"; mso-ansi-font-size:12.0pt; font-family:"Courier New"; mso-ascii-font-family:"Courier New"; mso-fareast-font-family:"Times New Roman"; mso-hansi-font-family:"Courier New";} .MsoChpDefault {mso-style-type:export-only; mso-default-props:yes; font-size:10.0pt; mso-ansi-font-size:10.0pt; mso-bidi-font-size:10.0pt; mso-fareast-font-family:"MS Mincho";} <at> page WordSection1 {size:612.0pt 792.0pt; margin:72.0pt 72.0pt 72.0pt 72.0pt; mso-header-margin:36.0pt; mso-footer-margin:36.0pt; mso-paper-source:0;} div.WordSection1 {page:WordSection1;} -->
Note that all examples use Transport Sessions based on the SCTP protocol, as simplified use cases. However, the protocol would be important in situations such as an Intermediate Conversion Process doing transport protocol conversion. 3.2.2. Template Management With New Template Records The second case is a situation where the IPFIX Mediator generates new (Options) Template Records compared to the

"compared to" doesn't seem right here.
NEW:

The second case is a situation where the IPFIX Mediator generates new (Options) Template Records as a result of the Intermediate Process.

<!-- /* Font Definitions */ <at> font-face {font-family:Batang; panose-1:2 3 6 0 0 1 1 1 1 1; mso-font-alt:&#48148;&#53461;; mso-font-charset:129; mso-generic-font-family:roman; mso-font-pitch:variable; mso-font-signature:-1342176593 1775729915 48 0 524447 0;} <at> font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4; mso-font-charset:0; mso-generic-font-family:roman; mso-font-pitch:variable; mso-font-signature:-1610611985 1107304683 0 0 159 0;} <at> font-face {font-family:"\ <at> Batang"; panose-1:2 3 6 0 0 1 1 1 1 1; mso-font-charset:129; mso-generic-font-family:roman; mso-font-pitch:variable; mso-font-signature:-1342176593 1775729915 48 0 524447 0;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {mso-style-unhide:no; mso-style-qformat:yes; mso-style-parent:""; margin-top:0cm; margin-right:0cm; margin-bottom:12.0pt; margin-left:21.6pt; line-height:12.0pt; mso-line-height-rule:exactly; mso-pagination:widow-orphan; tab-stops:21.6pt 43.2pt 64.8pt 86.4pt 108.0pt 129.6pt 151.2pt 172.8pt 194.4pt 216.0pt 237.6pt 259.2pt 280.8pt 302.4pt 324.0pt 345.6pt 367.2pt 388.8pt 410.4pt 432.0pt 16.0cm 475.2pt 496.8pt; font-size:12.0pt; font-family:"Courier New"; mso-fareast-font-family:Batang;} p.RFCText, li.RFCText, div.RFCText {mso-style-name:"RFC Text"; mso-style-priority:99; mso-style-unhide:no; mso-style-link:"RFC Text Char"; margin-top:0cm; margin-right:0cm; margin-bottom:0cm; margin-left:21.6pt; margin-bottom:.0001pt; line-height:12.0pt; mso-line-height-rule:exactly; mso-pagination:widow-orphan; font-size:12.0pt; mso-bidi-font-size:10.0pt; font-family:"Courier New"; mso-fareast-font-family:"Times New Roman"; mso-bidi-font-family:"Times New Roman";} span.RFCTextChar {mso-style-name:"RFC Text Char"; mso-style-priority:99; mso-style-unhide:no; mso-style-locked:yes; mso-style-link:"RFC Text"; mso-ansi-font-size:12.0pt; font-family:"Courier New"; mso-ascii-font-family:"Courier New"; mso-fareast-font-family:"Times New Roman"; mso-hansi-font-family:"Courier New";} .MsoChpDefault {mso-style-type:export-only; mso-default-props:yes; font-size:10.0pt; mso-ansi-font-size:10.0pt; mso-bidi-font-size:10.0pt; mso-fareast-font-family:"MS Mincho";} <at> page WordSection1 {size:612.0pt 792.0pt; margin:72.0pt 72.0pt 72.0pt 72.0pt; mso-header-margin:36.0pt; mso-footer-margin:36.0pt; mso-paper-source:0;} div.WordSection1 {page:WordSection1;} -->


received ones. In such a situation, the IPFIX Mediator doesn't need to maintain a Template Mapping, as it generates its own series of (Options) Template Records. However, the following special case might still require a Template Mapping, i.e. a situation where the IPFIX Mediator, typically containing an Intermediate Conversion Process, Intermediate Aggregation Process [IPFIX-MED-AGGR], or Intermediate Anonymization Process in case of black-marker Anonymization [RFC6235], generates new (Options) Template Records based on what it receives from the Exporter(s), and based on the Intermediate Process function. In such a case, <Claise, et. Al> Expires January 6, 2012 [Page 14] Internet-Draft <Protocol for IPFIX Mediations> July 2011 it's interesting to keep the correlation between the received (Options) Template Records and exported Derived Options)

(Options)
Done.

Template Records in the Template Mapping. Therefore, the IPFIX Mediator MAY maintain a Template Mapping composed of received (Options) Template Records and exported derived Options) Template Records: - for each received (Options) Template Record: Template Record Flow Keys and non Flow Keys, Template ID, Observation Domain, and Transport Session Information - for each exported derived Options) Template Record: Template Record Flow Keys and non Flow Keys, Template ID, Collector, Observation Domain, and Transport Session Information If an IPFIX Mediator receives an IPFIX Withdrawal Message for a (Options) Template Record that is not used anymore as the basis of an inferred (Options) Template Records, the IPFIX Mediator

Use "Record" or "Record(s)" to match with "an".
Done.


SHOULD export the appropriate IPFIX Withdrawal Message(s) for the inferred (Options) Template Record on the outgoing Transport Session, and remove the corresponding entry in the Template Mapping. The following two examples illustrate this. First, consider an IPFIX Mediator hosting an Intermediate Aggregation Process that generates time-series traffic octet counts per source IP address (as in the example in section 8.1 of [IPFIX-MED-AGGR]). Here, the Intermediate Process accepts Flow Records fitting any Template, discards all Information Elements other than the sourceIPv[46]Address and octetDeltaCount, aggregates these across all original Exporters in a given regular time interval, and exports Flow Records according to a Template Record containing flowStartTimeMilliseconds, flowEndTimeMilliseconds, sourceIPv[46]Address, and octetDeltaCount. In this case, no Template Mapping is necessary. New Templates and Template Withdrawals in the Transport Sessions from the Original Exporters are handled as they would be at any Collecting Process. Records according to Templates which do not contain at least a timestamp, sourceIPv[46]Address, and octetDeltaCount IE are simply discarded by the Collector. Next, consider a more generic case of this Intermediate Aggregation Process, which creates time-series aggregates across all Original Exporters, imposing a time interval but keeping a subset of the incoming Flow Key received from the Original <Claise, et. Al> Expires January 6, 2012 [Page 15] Internet-Draft <Protocol for IPFIX Mediations> July 2011 Exporter. In this case, a Template Mapping is necessary, as there is a relationship between incoming and outgoing Templates. .--------. tid 256 (src) |IPFIX | |Exporter|----+ |#1 | | '--------' | .--------. | .----------. .---------. |IPFIX | '--------->| | | | |Exporter|-------------->|IPFIX |------------->|IPFIX | |#2 | tid 257 (src) |Mediator |tid 256 (src) |Collector| '--------' +--------->| | 257 (dst) | | .--------. | '----------' '---------' |IPFIX | | |Exporter|----' |#3 | tid 257 (dst) '--------' Figure C: Intermediate Aggregation Process Example

Personally, I feel that "src" and "dst" clutter this figure without adding much.
At first I didn't understand what a src or dst template ID was.
removed.


In Figure C, above, the Mediator accepts a Template Record containing only the sourceIPv4Address as the Flow Key from Exporters 1 and 2, and a Template Record containing only the destinationIPv4Address as the Flow Key from exporter 3. It exports time-series source aggregates as Template ID 256, and time-series destination aggregates as Template ID 257. The Template Entries in this case are as follows: Template Entry A: Incoming Transport Session Information (from Exporter#1): Source IP: <Exporter#1 export IP address> Destination IP: <IPFIX Mediator IP address> Protocol: SCTP Source Port: <source port> Destination Port: 4739 (IPFIX) Observation Domain Id: <Observation Domain ID> Template Id: 256 Flow Keys: sourceIPv4Address Non Flow Keys: octetDeltaCount, [others] Template Entry B: Incoming Transport Session Information (from Exporter#2): Source IP: <Exporter#2 export IP address> Destination IP: <IPFIX Mediator IP address> Protocol: SCTP Source Port: <source port> <Claise, et. Al> Expires January 6, 2012 [Page 16] Internet-Draft <Protocol for IPFIX Mediations> July 2011 Destination Port: 4739 (IPFIX) Observation Domain Id: <Observation Domain ID> Template Id: 257 Flow Keys: sourceIPv4Address Non Flow Keys: octetDeltaCount, [others] Template Entry C: Incoming Transport Session Information (from Exporter#3): Source IP: <Exporter#3 export IP address> Destination IP: <IPFIX Mediator IP address> Protocol: SCTP Source Port: <source port> Destination Port: 4739 (IPFIX) Observation Domain Id: <Observation Domain ID> Template Id: 257 Flow Keys: destinationIPv4Address Non Flow Keys: octetDeltaCount, [others] Template Entry D: Outgoing Transport Session Information (to IPFIX Collector): Source IP: <IPFIX Mediator export IP address> Destination IP: <IPFIX Collector IP address> Protocol: SCTP Source Port: <source port> Destination Port: 4739 (IPFIX) Observation Domain Id: <Observation Domain ID> Template Id: 256 Flow Keys: sourceIPv4Address Non Flow Keys: octetDeltaCount Template Entry E: Outgoing Transport Session Information (to IPFIX Collector): Source IP: <IPFIX Mediator export IP address> Destination IP: <IPFIX Collector IP address> Protocol: SCTP Source Port: <source port> Destination Port: 4739 (IPFIX) Observation Domain Id: <Observation Domain ID> Template Id: 257 Flow Keys: destinationIPv4Address Non Flow Keys: octetDeltaCount The Template Mapping corresponding to the figure C can be

d/the/
Done.


displayed as: Template Entry A <----> Template Entry D Template Entry B <----> Template Entry D <Claise, et. Al> Expires January 6, 2012 [Page 17] Internet-Draft <Protocol for IPFIX Mediations> July 2011 Template Entry C <----> Template Entry E Note that all examples use Transport Sessions based on the SCTP protocol, as simplified use cases. However, the protocol would be important in situations such as an Intermediate Conversion Process doing transport protocol conversion. 3.3. Time Management The IPFIX Message Header "Export Time" field is the time in seconds since 0000 UTC Jan 1, 1970, at which the IPFIX Message Header leaves the IPFIX Mediator. However, in the specific case

The header isn't disembodied. d/Header/
Good catch.


of an IPFIX Mediator containing an Intermediate Conversion Process, the IPFIX Mediator MAY keep the export time received from the incoming Transport Session.

Very generous. Why?
List as an open issue.


It is RECOMMENDED that Mediators handle time using absolute timestamps (e.g. flowStartSeconds, flowStartMilliseconds, flowStartNanoseconds), which are specified relative to the UNIX epoch (00:00 UTC 1 Jan 1970), where possible, rather than relative timestamps (e.g. flowStartSysUpTime, flowStartDeltaMicroseconds), which are specified relative to protocol structures such as system initialization or message export time. The latter are difficult to manage for two reasons. First, they require constant translation, as the system initialization time of an intermediate system and the export time of an intermediate message will change across mediation operations. Further, relative timestamps introduce range problems. For example, when using the flowStartDeltaMicroseconds and flowEndDeltaMicroseconds Information Elements [RFC5102], the

Should you cite IANA here instead?
Listed as an open issue.


Data Record must be exported within a maximum of 71 minutes after its creation. Otherwise, the 32-bit counter would not be sufficient to contain the flow start time offset. Those time constraints might be incompatible with some of the Intermediate Processes: Intermediate Aggregation Process (temporal) and Intermediate Correlation Process, for example. When an Intermediate Aggregation Process aggregates information from different Flow Records, the typical reporting times SHOULD BE the minimum of the start times and the maximum of the end

s/BE/be/
;-)


times. However, if the Flow Records do not overlap, i.e. if there is a time gap between the times in the Flow Records, then the report may be inaccurate. The IPFIX Mediator is only reporting what it knows, on the basis of the information made <Claise, et. Al> Expires January 6, 2012 [Page 18] Internet-Draft <Protocol for IPFIX Mediations> July 2011 available to it - and there may not have been any data to observe during the gap. Then again, if there is an overlap in timestamps, there's the potential of double-accounting: different Observation Points may have observed the same traffic simultaneously. Therefore, as there is not a single rule that fits all different situations, the precise rules of applying the Flow Record timestamps in IPFIX Mediators is out of the scope of this document. However, some more specifications related to the

Being a hard problem doesn't make it out of scope. I think this is exactly something that should be specified here. Else, where?
Listed as an open issue


specific case of aggregation in space and time are specified in

"specifications... are specified" seems clumsy. s/specified/given/
Done.


[IPFIX-MED-AGGR], and MUST be followed. 3.4. Observation Point Management Depending on the use case, top Collectors may need to receive

What are "top collectors"?
top, as top collector in a chain of collectors.
NEW:
Depending on the use case, the Collector in an Exporter-Mediator-Collector structure model may need to receive the Original Observation Point(s),


note that
<!-- /* Font Definitions */ <at> font-face {font-family:"MS Mincho"; panose-1:2 2 6 9 4 2 5 8 3 4; mso-font-alt:"&#65325;&#65331; &#26126;&#26397;"; mso-font-charset:128; mso-generic-font-family:modern; mso-font-pitch:fixed; mso-font-signature:-1610612033 1757936891 16 0 131231 0;} <at> font-face {font-family:Batang; panose-1:2 3 6 0 0 1 1 1 1 1; mso-font-alt:&#48148;&#53461;; mso-font-charset:129; mso-generic-font-family:roman; mso-font-pitch:variable; mso-font-signature:-1342176593 1775729915 48 0 524447 0;} <at> font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4; mso-font-charset:0; mso-generic-font-family:roman; mso-font-pitch:variable; mso-font-signature:-1610611985 1107304683 0 0 159 0;} <at> font-face {font-family:"\ <at> Batang"; panose-1:2 3 6 0 0 1 1 1 1 1; mso-font-charset:129; mso-generic-font-family:roman; mso-font-pitch:variable; mso-font-signature:-1342176593 1775729915 48 0 524447 0;} <at> font-face {font-family:"\ <at> MS Mincho"; panose-1:2 2 6 9 4 2 5 8 3 4; mso-font-charset:128; mso-generic-font-family:modern; mso-font-pitch:fixed; mso-font-signature:-1610612033 1757936891 16 0 131231 0;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {mso-style-unhide:no; mso-style-qformat:yes; mso-style-parent:""; margin-top:0cm; margin-right:0cm; margin-bottom:12.0pt; margin-left:21.6pt; line-height:12.0pt; mso-line-height-rule:exactly; mso-pagination:widow-orphan; tab-stops:21.6pt 43.2pt 64.8pt 86.4pt 108.0pt 129.6pt 151.2pt 172.8pt 194.4pt 216.0pt 237.6pt 259.2pt 280.8pt 302.4pt 324.0pt 345.6pt 367.2pt 388.8pt 410.4pt 432.0pt 16.0cm 475.2pt 496.8pt; font-size:12.0pt; font-family:"Courier New"; mso-fareast-font-family:Batang;} .MsoChpDefault {mso-style-type:export-only; mso-default-props:yes; font-size:10.0pt; mso-ansi-font-size:10.0pt; mso-bidi-font-size:10.0pt; mso-fareast-font-family:"MS Mincho";} <at> page WordSection1 {size:612.0pt 792.0pt; margin:72.0pt 72.0pt 72.0pt 72.0pt; mso-header-margin:36.0pt; mso-footer-margin:36.0pt; mso-paper-source:0;} div.WordSection1 {page:WordSection1;} --> "Exporter-Mediator-Collector structure model" was used in RFC5982 (Mediation requirements) <!-- /* Font Definitions */ <at> font-face {font-family:Batang; panose-1:2 3 6 0 0 1 1 1 1 1; mso-font-alt:&#48148;&#53461;; mso-font-charset:129; mso-generic-font-family:roman; mso-font-pitch:variable; mso-font-signature:-1342176593 1775729915 48 0 524447 0;} <at> font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4; mso-font-charset:0; mso-generic-font-family:roman; mso-font-pitch:variable; mso-font-signature:-1610611985 1107304683 0 0 159 0;} <at> font-face {font-family:"\ <at> Batang"; panose-1:2 3 6 0 0 1 1 1 1 1; mso-font-charset:129; mso-generic-font-family:roman; mso-font-pitch:variable; mso-font-signature:-1342176593 1775729915 48 0 524447 0;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {mso-style-unhide:no; mso-style-qformat:yes; mso-style-parent:""; margin-top:0cm; margin-right:0cm; margin-bottom:12.0pt; margin-left:21.6pt; line-height:12.0pt; mso-line-height-rule:exactly; mso-pagination:widow-orphan; tab-stops:21.6pt 43.2pt 64.8pt 86.4pt 108.0pt 129.6pt 151.2pt 172.8pt 194.4pt 216.0pt 237.6pt 259.2pt 280.8pt 302.4pt 324.0pt 345.6pt 367.2pt 388.8pt 410.4pt 432.0pt 16.0cm 475.2pt 496.8pt; font-size:12.0pt; font-family:"Courier New"; mso-fareast-font-family:Batang;} .MsoChpDefault {mso-style-type:export-only; mso-default-props:yes; font-size:10.0pt; mso-ansi-font-size:10.0pt; mso-bidi-font-size:10.0pt; mso-fareast-font-family:"MS Mincho";} <at> page WordSection1 {size:612.0pt 792.0pt; margin:72.0pt 72.0pt 72.0pt 72.0pt; mso-header-margin:36.0pt; mso-footer-margin:36.0pt; mso-paper-source:0;} div.WordSection1 {page:WordSection1;} -->


the Original Observation Point(s), otherwise it may wrongly conclude that the IPFIX Device exporting the Flow Records to him, i.e. the IPFIX Mediator, directly observed the packets that

These singular pronouns don't match plural "top Collectors". Consider "they" and "them".
Done.


generated the Flow Records. Two new Information Element are

s/Element/Elements/
Done.


introduced to solve this use case: originalExporterIPv4Address and originalExporterIPv6Address. In the IPFIX Mediator, the Observation Point(s) may be represented by: - A single Original Exporter (represented by the originalExporterIPv4Address or originalExporterIPv6Address Information Elements) - A list of Original Exporter (represented by the
originalExporterIPv4Address or originalExporterIPv6Address Information Elements_)

d/_/


- A list of Original Exporter (represented by the originalExporterIPv4Address or originalExporterIPv6Address Information Elements), along with the associated interface (represented by the ingressInterface and/or egressInterface)

You've described "(list of originalExporterIPv[46]Address) + interface".
I think you meant, "list of (originalExporterIPv[46]Address + interface)".
Good catch!
NEW:

-  A list of Original Exporter interface(s) (represented by the originalExporterIPv4Address or originalExporterIPv6Address, the ingressInterface and/or egressInterface Information Elements, respectively)

<!-- /* Font Definitions */ <at> font-face {font-family:Wingdings; panose-1:5 0 0 0 0 0 0 0 0 0; mso-font-charset:2; mso-generic-font-family:auto; mso-font-pitch:variable; mso-font-signature:0 268435456 0 0 -2147483648 0;} <at> font-face {font-family:"MS Mincho"; panose-1:2 2 6 9 4 2 5 8 3 4; mso-font-alt:"&#65325;&#65331; &#26126;&#26397;"; mso-font-charset:128; mso-generic-font-family:modern; mso-font-pitch:fixed; mso-font-signature:-1610612033 1757936891 16 0 131231 0;} <at> font-face {font-family:Batang; panose-1:2 3 6 0 0 1 1 1 1 1; mso-font-alt:&#48148;&#53461;; mso-font-charset:129; mso-generic-font-family:roman; mso-font-pitch:variable; mso-font-signature:-1342176593 1775729915 48 0 524447 0;} <at> font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4; mso-font-charset:0; mso-generic-font-family:roman; mso-font-pitch:variable; mso-font-signature:-1610611985 1107304683 0 0 159 0;} <at> font-face {font-family:"\ <at> Batang"; panose-1:2 3 6 0 0 1 1 1 1 1; mso-font-charset:129; mso-generic-font-family:roman; mso-font-pitch:variable; mso-font-signature:-1342176593 1775729915 48 0 524447 0;} <at> font-face {font-family:"\ <at> MS Mincho"; panose-1:2 2 6 9 4 2 5 8 3 4; mso-font-charset:128; mso-generic-font-family:modern; mso-font-pitch:fixed; mso-font-signature:-1610612033 1757936891 16 0 131231 0;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {mso-style-unhide:no; mso-style-qformat:yes; mso-style-parent:""; margin-top:0cm; margin-right:0cm; margin-bottom:12.0pt; margin-left:21.6pt; line-height:12.0pt; mso-line-height-rule:exactly; mso-pagination:widow-orphan; tab-stops:21.6pt 43.2pt 64.8pt 86.4pt 108.0pt 129.6pt 151.2pt 172.8pt 194.4pt 216.0pt 237.6pt 259.2pt 280.8pt 302.4pt 324.0pt 345.6pt 367.2pt 388.8pt 410.4pt 432.0pt 16.0cm 475.2pt 496.8pt; font-size:12.0pt; font-family:"Courier New"; mso-fareast-font-family:Batang;} p.RFCText, li.RFCText, div.RFCText {mso-style-name:"RFC Text"; mso-style-priority:99; mso-style-unhide:no; mso-style-link:"RFC Text Char"; margin-top:0cm; margin-right:0cm; margin-bottom:0cm; margin-left:21.6pt; margin-bottom:.0001pt; line-height:12.0pt; mso-line-height-rule:exactly; mso-pagination:widow-orphan; font-size:12.0pt; mso-bidi-font-size:10.0pt; font-family:"Courier New"; mso-fareast-font-family:"Times New Roman"; mso-bidi-font-family:"Times New Roman";} span.RFCTextChar {mso-style-name:"RFC Text Char"; mso-style-priority:99; mso-style-unhide:no; mso-style-locked:yes; mso-style-link:"RFC Text"; mso-ansi-font-size:12.0pt; font-family:"Courier New"; mso-ascii-font-family:"Courier New"; mso-fareast-font-family:"Times New Roman"; mso-hansi-font-family:"Courier New";} .MsoChpDefault {mso-style-type:export-only; mso-default-props:yes; font-size:10.0pt; mso-ansi-font-size:10.0pt; mso-bidi-font-size:10.0pt; mso-fareast-font-family:"MS Mincho";} <at> page WordSection1 {size:612.0pt 792.0pt; margin:72.0pt 72.0pt 72.0pt 72.0pt; mso-header-margin:36.0pt; mso-footer-margin:36.0pt; mso-paper-source:0;} div.WordSection1 {page:WordSection1;} /* List Definitions */ <at> list l0 {mso-list-id:939407197; mso-list-type:hybrid; mso-list-template-ids:-2076254344 -1843766792 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;} <at> list l0:level1 {mso-level-start-at:6; mso-level-number-format:bullet; mso-level-text:-; mso-level-tab-stop:36.0pt; mso-level-number-position:left; text-indent:-18.0pt; font-family:"Courier New"; mso-fareast-font-family:"Times New Roman";} <at> list l0:level2 {mso-level-number-format:bullet; mso-level-text:o; mso-level-tab-stop:72.0pt; mso-level-number-position:left; text-indent:-18.0pt; font-family:"Courier New";} ol {margin-bottom:0cm;} ul {margin-bottom:0cm;} -->


- A list of Original Exporter (represented by the originalExporterIPv4Address or originalExporterIPv6Address Information Elements), along with the associated line card id (represented by the lineCardId)
NEW:

-  A list of Original Exporter line card (represented by the originalExporterIPv4Address or originalExporterIPv6Address, the lineCardId Information Elements, respectively)

<!-- /* Font Definitions */ <at> font-face {font-family:Wingdings; panose-1:5 0 0 0 0 0 0 0 0 0; mso-font-charset:2; mso-generic-font-family:auto; mso-font-pitch:variable; mso-font-signature:0 268435456 0 0 -2147483648 0;} <at> font-face {font-family:"MS Mincho"; panose-1:2 2 6 9 4 2 5 8 3 4; mso-font-alt:"&#65325;&#65331; &#26126;&#26397;"; mso-font-charset:128; mso-generic-font-family:modern; mso-font-pitch:fixed; mso-font-signature:-1610612033 1757936891 16 0 131231 0;} <at> font-face {font-family:Batang; panose-1:2 3 6 0 0 1 1 1 1 1; mso-font-alt:&#48148;&#53461;; mso-font-charset:129; mso-generic-font-family:roman; mso-font-pitch:variable; mso-font-signature:-1342176593 1775729915 48 0 524447 0;} <at> font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4; mso-font-charset:0; mso-generic-font-family:roman; mso-font-pitch:variable; mso-font-signature:-1610611985 1107304683 0 0 159 0;} <at> font-face {font-family:"\ <at> Batang"; panose-1:2 3 6 0 0 1 1 1 1 1; mso-font-charset:129; mso-generic-font-family:roman; mso-font-pitch:variable; mso-font-signature:-1342176593 1775729915 48 0 524447 0;} <at> font-face {font-family:"\ <at> MS Mincho"; panose-1:2 2 6 9 4 2 5 8 3 4; mso-font-charset:128; mso-generic-font-family:modern; mso-font-pitch:fixed; mso-font-signature:-1610612033 1757936891 16 0 131231 0;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {mso-style-unhide:no; mso-style-qformat:yes; mso-style-parent:""; margin-top:0cm; margin-right:0cm; margin-bottom:12.0pt; margin-left:21.6pt; line-height:12.0pt; mso-line-height-rule:exactly; mso-pagination:widow-orphan; tab-stops:21.6pt 43.2pt 64.8pt 86.4pt 108.0pt 129.6pt 151.2pt 172.8pt 194.4pt 216.0pt 237.6pt 259.2pt 280.8pt 302.4pt 324.0pt 345.6pt 367.2pt 388.8pt 410.4pt 432.0pt 16.0cm 475.2pt 496.8pt; font-size:12.0pt; font-family:"Courier New"; mso-fareast-font-family:Batang;} p.RFCText, li.RFCText, div.RFCText {mso-style-name:"RFC Text"; mso-style-priority:99; mso-style-unhide:no; mso-style-link:"RFC Text Char"; margin-top:0cm; margin-right:0cm; margin-bottom:0cm; margin-left:21.6pt; margin-bottom:.0001pt; line-height:12.0pt; mso-line-height-rule:exactly; mso-pagination:widow-orphan; font-size:12.0pt; mso-bidi-font-size:10.0pt; font-family:"Courier New"; mso-fareast-font-family:"Times New Roman"; mso-bidi-font-family:"Times New Roman";} span.RFCTextChar {mso-style-name:"RFC Text Char"; mso-style-priority:99; mso-style-unhide:no; mso-style-locked:yes; mso-style-link:"RFC Text"; mso-ansi-font-size:12.0pt; font-family:"Courier New"; mso-ascii-font-family:"Courier New"; mso-fareast-font-family:"Times New Roman"; mso-hansi-font-family:"Courier New";} .MsoChpDefault {mso-style-type:export-only; mso-default-props:yes; font-size:10.0pt; mso-ansi-font-size:10.0pt; mso-bidi-font-size:10.0pt; mso-fareast-font-family:"MS Mincho";} <at> page WordSection1 {size:612.0pt 792.0pt; margin:72.0pt 72.0pt 72.0pt 72.0pt; mso-header-margin:36.0pt; mso-footer-margin:36.0pt; mso-paper-source:0;} div.WordSection1 {page:WordSection1;} /* List Definitions */ <at> list l0 {mso-list-id:939407197; mso-list-type:hybrid; mso-list-template-ids:-2076254344 -1843766792 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;} <at> list l0:level1 {mso-level-start-at:6; mso-level-number-format:bullet; mso-level-text:-; mso-level-tab-stop:36.0pt; mso-level-number-position:left; text-indent:-18.0pt; font-family:"Courier New"; mso-fareast-font-family:"Times New Roman";} <at> list l0:level2 {mso-level-number-format:bullet; mso-level-text:o; mso-level-tab-stop:72.0pt; mso-level-number-position:left; text-indent:-18.0pt; font-family:"Courier New";} ol {margin-bottom:0cm;} ul {margin-bottom:0cm;} -->

Today's OP could be at many more places than an interface or LC. We need to move away from this old thinking.


- Any combination or list of Information Elements representing Observation Points.

Consider removing the previous two points and using them as specific examples of this point.
Good suggestion.


Some Information Elements characterizing the Observation Point may be added. For example, the flowDirection Information Element specifies the direction of the observation, and, as such, characterizes the Observation Point. <Claise, et. Al> Expires January 6, 2012 [Page 19] Internet-Draft <Protocol for IPFIX Mediations> July 2011 Any combination of the above examples is possible. For example, in case of an Intermediate Aggregation Process, an Original Observation Point can be composed of: exporterIPv4Address 192.0.2.1 exporterIPv4Address 192.0.2.2, interface ethernet 0, direction ingress interface ethernet 1, direction ingress interface serial 1, direction egress interface serial 2, direction egress exporterIPv4Address 192.0.2.3, lineCardId 1, direction ingress If the Original Observation Point is composed of a list, then the IPFIX Structured Data [IPFIX-STRUCT] MUST be used to export it from the IPFIX Mediator. The most generic way to export the Original Observation Point is to use a subTemplateMultiList, with the semantic "exactlyOneOf". Taking back the previous example, the following encoding can be

d/back/
done.


used: Template Record 257: exporterIPv4Address Template Record 258: exporterIPv4Address, basicList of ingressInterface, flowDirecdtion

s/flowDirecdtion/flowDirection/
Done.


Template Record 259: exporterIPv4Address, lineCardId, flowDirection

How does the mediator come to know where the OPs are in the original devices?
Either

eg, suppose the OP is at the QoS process in order to verify SLA. Although interface IDs and/or LC IDs may be exported, these might incorrectly imply multiple OPs.


The Original Observation Point is modeled with the Data Records corresponding to either Template Record 1, Template Record 2, or Template Record 3 but not more than one of these ("exactlyOneOf" semantic). This implies that the Flow was observed at exactly one of the Observation Points reported. When an IPFIX Mediator receives Flow Records containing the Original Observation Point Information Element, i.e.

Aha! You expect the original exporter to populate FR with OOPIE, just in case a mediator is present? LOL.
No existing exporters do that today. How does the mediator work?
Not exactly. The point in that sentence is ...  "SHOULD NOT modify its value(s)"
However, you have a good point.
NEW to the 1st paragraph in this section;
Mediator-Collector structure model may need to receive the Original Observation Point(s), otherwise it may wrongly conclude that the IPFIX Device exporting the Flow Records to him, i.e. the IPFIX Mediator, directly observed the packets that generated the Flow Records.  Two new Information Elements are introduced to solve this use case: originalExporterIPv4Address and originalExporterIPv6Address.  Practically, the Original Exporters will not exporting these Information Elements. Therefore, the Intermediate Process SHOULD report the Original Observation Point(s) to the best of its knowledge.  Note that the Configuration Data Model for IPFIX and PSAMP [IPFIX-CONF] may help.


<!-- /* Font Definitions */ <at> font-face {font-family:"MS Mincho"; panose-1:2 2 6 9 4 2 5 8 3 4; mso-font-alt:"&#65325;&#65331; &#26126;&#26397;"; mso-font-charset:128; mso-generic-font-family:modern; mso-font-pitch:fixed; mso-font-signature:-1610612033 1757936891 16 0 131231 0;} <at> font-face {font-family:Batang; panose-1:2 3 6 0 0 1 1 1 1 1; mso-font-alt:&#48148;&#53461;; mso-font-charset:129; mso-generic-font-family:roman; mso-font-pitch:variable; mso-font-signature:-1342176593 1775729915 48 0 524447 0;} <at> font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4; mso-font-charset:0; mso-generic-font-family:roman; mso-font-pitch:variable; mso-font-signature:-1610611985 1107304683 0 0 159 0;} <at> font-face {font-family:"\ <at> Batang"; panose-1:2 3 6 0 0 1 1 1 1 1; mso-font-charset:129; mso-generic-font-family:roman; mso-font-pitch:variable; mso-font-signature:-1342176593 1775729915 48 0 524447 0;} <at> font-face {font-family:"\ <at> MS Mincho"; panose-1:2 2 6 9 4 2 5 8 3 4; mso-font-charset:128; mso-generic-font-family:modern; mso-font-pitch:fixed; mso-font-signature:-1610612033 1757936891 16 0 131231 0;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {mso-style-unhide:no; mso-style-qformat:yes; mso-style-parent:""; margin-top:0cm; margin-right:0cm; margin-bottom:12.0pt; margin-left:21.6pt; line-height:12.0pt; mso-line-height-rule:exactly; mso-pagination:widow-orphan; tab-stops:21.6pt 43.2pt 64.8pt 86.4pt 108.0pt 129.6pt 151.2pt 172.8pt 194.4pt 216.0pt 237.6pt 259.2pt 280.8pt 302.4pt 324.0pt 345.6pt 367.2pt 388.8pt 410.4pt 432.0pt 16.0cm 475.2pt 496.8pt; font-size:12.0pt; font-family:"Courier New","serif"; mso-fareast-font-family:Batang; mso-bidi-font-family:"Courier New";} a:link, span.MsoHyperlink {mso-style-priority:99; mso-style-unhide:no; color:blue; text-decoration:underline; text-underline:single;} a:visited, span.MsoHyperlinkFollowed {mso-style-noshow:yes; mso-style-priority:99; color:purple; mso-themecolor:followedhyperlink; text-decoration:underline; text-underline:single;} pre {mso-style-noshow:yes; mso-style-priority:99; mso-style-unhide:no; mso-style-link:"HTML Preformatted Char"; margin-top:0cm; margin-right:0cm; margin-bottom:12.0pt; margin-left:21.6pt; line-height:12.0pt; mso-line-height-rule:exactly; mso-pagination:widow-orphan; tab-stops:21.6pt 43.2pt 64.8pt 86.4pt 108.0pt 129.6pt 151.2pt 172.8pt 194.4pt 216.0pt 237.6pt 259.2pt 280.8pt 302.4pt 324.0pt 345.6pt 367.2pt 388.8pt 410.4pt 432.0pt 16.0cm 475.2pt 496.8pt; font-size:10.0pt; font-family:"Courier New","serif"; mso-fareast-font-family:Batang; mso-bidi-font-family:"Courier New";} span.HTMLPreformattedChar {mso-style-name:"HTML Preformatted Char"; mso-style-noshow:yes; mso-style-priority:99; mso-style-unhide:no; mso-style-locked:yes; mso-style-link:"HTML Preformatted"; font-family:"Courier New","serif"; mso-ascii-font-family:"Courier New"; mso-fareast-font-family:Batang; mso-hansi-font-family:"Courier New"; mso-bidi-font-family:"Courier New";} .MsoChpDefault {mso-style-type:export-only; mso-default-props:yes; font-size:10.0pt; mso-ansi-font-size:10.0pt; mso-bidi-font-size:10.0pt; mso-fareast-font-family:"MS Mincho";} <at> page WordSection1 {size:612.0pt 792.0pt; margin:72.0pt 72.0pt 72.0pt 72.0pt; mso-header-margin:36.0pt; mso-footer-margin:36.0pt; mso-paper-source:0;} div.WordSection1 {page:WordSection1;} -->
Also listed as an open issue, for discussion.


originalExporterIPv6Address or originalExporterIPv4Address, the IPFIX Mediator SHOULD NOT modify its value(s) when composing new Flow Records in the general case. Known exceptions include anonymization per [RFC6235] section 7.2.4 and an Intermediate Correlation Process rewriting addresses across NAT. In other words, the Original Observation Point should not be replaced the IPFIX Mediator Observation Point. The daisy chain of (Exporter, Observation Point) representing the path the Flow <Claise, et. Al> Expires January 6, 2012 [Page 20] Internet-Draft <Protocol for IPFIX Mediations> July 2011 Records took from the Exporter to the top Collector, via the IPFIX Mediator(s) is out of the scope of this specification.

Why do you say it's out of scope? Where else would you expect it to be specified?
Question: Do you believe it's important to report that the flow record was exported from exporter 1 via mediator 1 via mediator 2 via mediator 3 to collector 1?



3.4.1. Observation Domain Management In any case, the Observation Domain ID of any IPFIX Message containing Flow Records relevant to no particular Observation Domain, or to multiple Observation Domains, MUST have an Observation Domain ID of 0, as in section 3.1 above, and section 3.1 of [RFC5101]. IPFIX Mediators that do not change (Options) Template Records MUST maintain a Template Mapping, as detailed in section 3.2.1, to ensure that the combination of Observation Domain IDs and Template IDs do not collide on export. For IPFIX Mediators that export New (Options) Template Records unchanged, as in section 3.2.2, there are two options for Observation Domain ID management. The first and simplest of these is to completely decouple exported Observation Domain IDs from received Observation Domain IDs; the IPFIX Mediator, in this case, comprises its own set of Observation Domain(s) independent of the Observation Domain(s) of the Original Exporters. The second option is to provide or maintain a Template Mapping for received (Options) Template Records and exported inferred (Options) Template Records, along with the appropriate Observation Domain IDs per Transport Session, which ensures that the combination of Observation Domain IDs and Template IDs do not collide on export. In some cases where the IPFIX Message Header can't contain a consistent Observation Domain for the entire IPFIX Message, but the Flow Records exported from the IPFIX Mediator should anyway contain the Observation Domain of the Original Exporter, the (Options) Template Record must contain the originalObservationDomainId Information Element. When an IPFIX Mediator receives Flow Records containing the originalObservationDomainId Information Element, the IPFIX Mediator MUST NOT modify its value(s) when composing new Flow Records with the originalObservationDomainId Information Element. <Claise, et. Al> Expires January 6, 2012 [Page 21] Internet-Draft <Protocol for IPFIX Mediations> July 2011 3.5. Specific Reporting Requirements Some specific Options Templates and Options Template Records are necessary to provide extra information about the Flow Records and about the Metering Process. The Options Template Records defined in these subsections, which impose some constraints on the Metering Process and Exporting Process implementations in Intermediate Processes, MAY be implemented. If implemented, the specific Option Templates SHOULD be implemented as specified in these subsections. The minimum set of Information Elements is always specified in these Specific IPFIX Options Templates. Nevertheless, extra

Why is "Specific" capitalised?
corrected.


Information Elements may be used in these specific Options Templates.

Other things I'd like to see in this section:

What about IE ordering? May an exporter re-order received fields? eg, two devices sending the same information, though with the fields in a different order. Or the mediator is extracting the same information from two sources. That seems to be a valid scenario. eg, this reduces the number of templates received at the collector.

What about temporal re-ordering? How should a mediator deal with out-of-order data coming from multiple devices? It can't expect all received data to be in time order.

What should a mediator do with a field which it doesn't know/understand? Inevitably, exporters will be updated without mediators keeping in step. It's also very likely that mediators will see Enterprise-specific IEs. May a mediator re-export unknown IEs unchanged, or should it drop them? Presumably a mediator may report received Enterprise-specific IEs even from multiple different Enterprises.

What if an unknown field depends on the field ordering? eg, it's a bitfield like flowKeyIndicator. Re-ordering, adding or removing fields breaks the meaning of this field, so it can't be passed on. It can only be used if the received fields are reported unchanged.
Listed as an open issue.


3.5.1. The Flow Keys Options Template Exactly like the IPFIX protocol [RFC5101], the Flow Keys Option Template specifies the structure of a Data Record for reporting the Flow Keys of reported Flows. A Flow Keys Data Record extends a particular Template Record that is referenced by its templateId identifier. The Template Record is extended by specifying which of the Information Elements contained in the corresponding Data Records describe Flow properties that serve as Flow Keys of the reported Flow. The Flow Keys Option Template SHOULD contain the following Information Elements that are defined in [RFC5102] templateId An identifier of a Template. This Information Element MUST be defined as a Scope Field. flowKeyIndicator Bitmap with the positions of the Flow Keys in the Data Records.

As a general point, can you space all your lists, with space before and after too?
It's less easy to read when all the text is jammed together.
Done.


When any Intermediate Process changes the Flow Keys, the Flow Keys Option Template MUST include the new set of Flow Keys. Typically, an Intermediate Aggregation Process keeps or reduces the number of Flow Keys

Missing full-stop here.
Done.

Consider mentioning how it can increase the number of keys. eg, by adding info about the OP or Exporter.
Good point.
I added:

However, the number of Flow Keys may increase when the Original Exporter or/and Original Observation Point is/are added.

<!-- /* Font Definitions */ <at> font-face {font-family:"MS Mincho"; panose-1:2 2 6 9 4 2 5 8 3 4; mso-font-alt:"&#65325;&#65331; &#26126;&#26397;"; mso-font-charset:128; mso-generic-font-family:modern; mso-font-pitch:fixed; mso-font-signature:-1610612033 1757936891 16 0 131231 0;} <at> font-face {font-family:Batang; panose-1:2 3 6 0 0 1 1 1 1 1; mso-font-alt:&#48148;&#53461;; mso-font-charset:129; mso-generic-font-family:roman; mso-font-pitch:variable; mso-font-signature:-1342176593 1775729915 48 0 524447 0;} <at> font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4; mso-font-charset:0; mso-generic-font-family:roman; mso-font-pitch:variable; mso-font-signature:-1610611985 1107304683 0 0 159 0;} <at> font-face {font-family:"\ <at> Batang"; panose-1:2 3 6 0 0 1 1 1 1 1; mso-font-charset:129; mso-generic-font-family:roman; mso-font-pitch:variable; mso-font-signature:-1342176593 1775729915 48 0 524447 0;} <at> font-face {font-family:"\ <at> MS Mincho"; panose-1:2 2 6 9 4 2 5 8 3 4; mso-font-charset:128; mso-generic-font-family:modern; mso-font-pitch:fixed; mso-font-signature:-1610612033 1757936891 16 0 131231 0;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {mso-style-unhide:no; mso-style-qformat:yes; mso-style-parent:""; margin-top:0cm; margin-right:0cm; margin-bottom:12.0pt; margin-left:21.6pt; line-height:12.0pt; mso-line-height-rule:exactly; mso-pagination:widow-orphan; tab-stops:21.6pt 43.2pt 64.8pt 86.4pt 108.0pt 129.6pt 151.2pt 172.8pt 194.4pt 216.0pt 237.6pt 259.2pt 280.8pt 302.4pt 324.0pt 345.6pt 367.2pt 388.8pt 410.4pt 432.0pt 16.0cm 475.2pt 496.8pt; font-size:12.0pt; font-family:"Courier New","serif"; mso-fareast-font-family:Batang; mso-bidi-font-family:"Courier New";} p.RFCText, li.RFCText, div.RFCText {mso-style-name:"RFC Text"; mso-style-priority:99; mso-style-unhide:no; mso-style-link:"RFC Text Char"; margin-top:0cm; margin-right:0cm; margin-bottom:0cm; margin-left:21.6pt; margin-bottom:.0001pt; line-height:12.0pt; mso-line-height-rule:exactly; mso-pagination:widow-orphan; font-size:12.0pt; mso-bidi-font-size:10.0pt; font-family:"Courier New","serif"; mso-fareast-font-family:"Times New Roman"; mso-bidi-font-family:"Times New Roman";} span.RFCTextChar {mso-style-name:"RFC Text Char"; mso-style-priority:99; mso-style-unhide:no; mso-style-locked:yes; mso-style-link:"RFC Text"; mso-ansi-font-size:12.0pt; font-family:"Courier New","serif"; mso-ascii-font-family:"Courier New"; mso-fareast-font-family:"Times New Roman"; mso-hansi-font-family:"Courier New";} .MsoChpDefault {mso-style-type:export-only; mso-default-props:yes; font-size:10.0pt; mso-ansi-font-size:10.0pt; mso-bidi-font-size:10.0pt; mso-fareast-font-family:"MS Mincho";} <at> page WordSection1 {size:612.0pt 792.0pt; margin:72.0pt 72.0pt 72.0pt 72.0pt; mso-header-margin:36.0pt; mso-footer-margin:36.0pt; mso-paper-source:0;} div.WordSection1 {page:WordSection1;} -->


3.5.2. IPFIX Protocol Options Template The "Metering Process Statistics Options Template", "The Metering Process Reliability Statistics Options Template", and "The Exporting Process Reliability Statistics Options Template", <Claise, et. Al> Expires January 6, 2012 [Page 22] Internet-Draft <Protocol for IPFIX Mediations> July 2011 as specified in [RFC5101], SHOULD be implemented on the IFPIX

s/IFPIX/IPFIX/
;-)


Mediator. Refer to the document specifying a particular Intermediate Process type for specific values for these Options Template Records. For example, in case of an Intermediate Aggregation Process, [IPFIX-MED-AGGR] must specify which values to insert

s/must specify/specifies/
done.


into the fields of "Metering Process Statistics Options Template", "The Metering Process Reliability Statistics Options Template", and "The Exporting Process Reliability Statistics Options Template" 3.5.3. IPFIX Mediator Options Template There is no need for a specific Options Template for the IPFIX Mediator; instead, each Intermediate Process type requires some particular metadata. For example, a specification of IPFIX flow Anonymization including an Options Template for the export of metadata about Anonymized flows is described in [RFC6235]; when Anonymizing Flows Records, IPFIX Mediators SHOULD add the Options Template specified therein to annotate the exported data. Transport Session Management SCTP [RFC4960] using the PR-SCTP extension specified in [RFC3758] MUST be implemented by all compliant IPFIX Mediator implementations. UDP [UDP] MAY also be implemented by compliant IPFIX Mediator implementations. TCP [TCP] MAY also be implemented by IPFIX Mediator compliant implementations.

For consistency, you should refer to these by their RFC numbers: "TCP [RFC793]", "UDP [RFC768]".
Done.


PR-SCTP SHOULD be used in deployments where IPFIX Mediators and Collectors are communicating over links that are susceptible to congestion. PR-SCTP is capable of providing any required degree of reliability. TCP MAY be used in deployments where IPFIX Mediators and Collectors communicate over links that are susceptible to congestion, but PR-SCTP is preferred due to its ability to limit back pressure on Exporters and its message versus stream orientation. UDP MAY be used, although it is not a congestion-aware protocol. However, the IPFIX traffic between IPFIX Mediator and Collector

However, in this case, the ...
Done.


MUST run in an environment where IPFIX traffic has been provisioned for, or is contained through some other means. <Claise, et. Al> Expires January 6, 2012 [Page 23] Internet-Draft <Protocol for IPFIX Mediations> July 2011 3.6. The Collecting Process's Side An IPFIX Mediator MUST produce IPFIX Messages understandable by a RFC5101-compliant IPFIX Collector, with the additional

Here you're limiting what mediators can do in future. If a future mediator wants to do something that's not backwards compatible with 5101 and specifies an extension to 5101 in order to do so, it'll break this MUST.
Removed the MUST
This section has been updated to be compliant with RFC5101bis
NEW:

An IPFIX Mediator produces IPFIX Messages understandable by a IPFIX-compliant Collector, with the additional specifications in IPFIX Structured Data [IPFIX-STRUCT].

 

Therefore the Collecting Process on the top Collector MUST support the IPFIX protocol [RFC5101bis] and the IPFIX Structured Data [IPFIX-STRUCT].

<!-- /* Font Definitions */ <at> font-face {font-family:"MS Mincho"; panose-1:2 2 6 9 4 2 5 8 3 4; mso-font-alt:"&#65325;&#65331; &#26126;&#26397;"; mso-font-charset:128; mso-generic-font-family:modern; mso-font-pitch:fixed; mso-font-signature:-1610612033 1757936891 16 0 131231 0;} <at> font-face {font-family:Batang; panose-1:2 3 6 0 0 1 1 1 1 1; mso-font-alt:&#48148;&#53461;; mso-font-charset:129; mso-generic-font-family:roman; mso-font-pitch:variable; mso-font-signature:-1342176593 1775729915 48 0 524447 0;} <at> font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4; mso-font-charset:0; mso-generic-font-family:roman; mso-font-pitch:variable; mso-font-signature:-1610611985 1107304683 0 0 159 0;} <at> font-face {font-family:"\ <at> Batang"; panose-1:2 3 6 0 0 1 1 1 1 1; mso-font-charset:129; mso-generic-font-family:roman; mso-font-pitch:variable; mso-font-signature:-1342176593 1775729915 48 0 524447 0;} <at> font-face {font-family:"\ <at> MS Mincho"; panose-1:2 2 6 9 4 2 5 8 3 4; mso-font-charset:128; mso-generic-font-family:modern; mso-font-pitch:fixed; mso-font-signature:-1610612033 1757936891 16 0 131231 0;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {mso-style-unhide:no; mso-style-qformat:yes; mso-style-parent:""; margin-top:0cm; margin-right:0cm; margin-bottom:12.0pt; margin-left:21.6pt; line-height:12.0pt; mso-line-height-rule:exactly; mso-pagination:widow-orphan; tab-stops:21.6pt 43.2pt 64.8pt 86.4pt 108.0pt 129.6pt 151.2pt 172.8pt 194.4pt 216.0pt 237.6pt 259.2pt 280.8pt 302.4pt 324.0pt 345.6pt 367.2pt 388.8pt 410.4pt 432.0pt 16.0cm 475.2pt 496.8pt; font-size:12.0pt; font-family:"Courier New","serif"; mso-fareast-font-family:Batang; mso-bidi-font-family:"Courier New";} p.RFCText, li.RFCText, div.RFCText {mso-style-name:"RFC Text"; mso-style-priority:99; mso-style-unhide:no; mso-style-link:"RFC Text Char"; margin-top:0cm; margin-right:0cm; margin-bottom:0cm; margin-left:21.6pt; margin-bottom:.0001pt; line-height:12.0pt; mso-line-height-rule:exactly; mso-pagination:widow-orphan; font-size:12.0pt; mso-bidi-font-size:10.0pt; font-family:"Courier New","serif"; mso-fareast-font-family:"Times New Roman"; mso-bidi-font-family:"Times New Roman";} span.RFCTextChar {mso-style-name:"RFC Text Char"; mso-style-priority:99; mso-style-unhide:no; mso-style-locked:yes; mso-style-link:"RFC Text"; mso-ansi-font-size:12.0pt; font-family:"Courier New","serif"; mso-ascii-font-family:"Courier New"; mso-fareast-font-family:"Times New Roman"; mso-hansi-font-family:"Courier New";} .MsoChpDefault {mso-style-type:export-only; mso-default-props:yes; font-size:10.0pt; mso-ansi-font-size:10.0pt; mso-bidi-font-size:10.0pt; mso-fareast-font-family:"MS Mincho";} <at> page WordSection1 {size:612.0pt 792.0pt; margin:72.0pt 72.0pt 72.0pt 72.0pt; mso-header-margin:36.0pt; mso-footer-margin:36.0pt; mso-paper-source:0;} div.WordSection1 {page:WordSection1;} -->



specification in the IPFIX Structured Data [IPFIX-STRUCT].

"specifications"
d/the/
Done.


Therefore the Collecting Process on the top Collector MUST support the IPFIX protocol [RFC5101] and the IPFIX Structured Data [IPFIX-STRUCT].

3.7. Configuration Management In some cases such as an Intermediate Aggregation Process aggregating Flow Records from multiple Original Exporters, a consistent configuration of the Metering Processes and Exporting Processes on these Original offers some advantages. For

Original Exporters.
Done.


example, consistent active timeout, inactive timeout, and/or consistent export time allows to compare the number of the Flow Records per period of time. For example, consistent Sampling algorithm and parameters might allow to compare Flow Records accuracy.

Either s/allow to compare/allows comparison of/, or put "to be compared" at the end:

    consistent active timeout, inactive timeout, and/or consistent export time allows
    the number of the Flow Records per period of time to be compared.
    For example, consistent Sampling algorithm and parameters might allow Flow Records accuracy to be compared.
Done.


While this is tempting to include all configuration parameters in Flow Records for the IPFIX Mediator to draw its own conclusion, the consistency of the configuration should be verified out of band, with the MIB modules ([RFC5815] and [PSAMP-MIB] or with the Configuration Data Model for IPFIX and PSAMP [IPFIX-CONF]

[PSAMP-MIB])
Missing full-stop.
Done.


4. New Information Elements EDITOR NOTE: please change the TBD1, TBD2, and TBD3, with the IANA newly assigned numbers. 4.1. - originalExporterIPv4Address

Remove the hyphen (dash) from the section title.
done.


Description: The IPv4 address used by the Exporting Process on the Original Exporter. This is used by an IPFIX Mediator Exporting Process to identify the Original Exporter. Abstract Data Type: ipv4Address ElementId: TBD3 Status: Proposed

Add "Semantics: identifier" for consistency with similar fields in the IANA IPFIX registry.

[Later] OK, there's some duplication with section 6. You could just list the Description and Type here, with a note that the full spec is in the IANA section below.
Done.
NEW:

Three new Information Elements are requested in this specifications: originalExporterIPv4Address, originalExporterIPv6Address, and originalObservationDomainId.  See Section 6.1. , Section 6.2. , and Section 6.3. , respectively, for the formal definitions.

<!-- /* Font Definitions */ <at> font-face {font-family:"MS Mincho"; panose-1:2 2 6 9 4 2 5 8 3 4; mso-font-alt:"&#65325;&#65331; &#26126;&#26397;"; mso-font-charset:128; mso-generic-font-family:modern; mso-font-pitch:fixed; mso-font-signature:-1610612033 1757936891 16 0 131231 0;} <at> font-face {font-family:Batang; panose-1:2 3 6 0 0 1 1 1 1 1; mso-font-alt:&#48148;&#53461;; mso-font-charset:129; mso-generic-font-family:roman; mso-font-pitch:variable; mso-font-signature:-1342176593 1775729915 48 0 524447 0;} <at> font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4; mso-font-charset:0; mso-generic-font-family:roman; mso-font-pitch:variable; mso-font-signature:-1610611985 1107304683 0 0 159 0;} <at> font-face {font-family:"\ <at> Batang"; panose-1:2 3 6 0 0 1 1 1 1 1; mso-font-charset:129; mso-generic-font-family:roman; mso-font-pitch:variable; mso-font-signature:-1342176593 1775729915 48 0 524447 0;} <at> font-face {font-family:"\ <at> MS Mincho"; panose-1:2 2 6 9 4 2 5 8 3 4; mso-font-charset:128; mso-generic-font-family:modern; mso-font-pitch:fixed; mso-font-signature:-1610612033 1757936891 16 0 131231 0;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {mso-style-unhide:no; mso-style-qformat:yes; mso-style-parent:""; margin-top:0cm; margin-right:0cm; margin-bottom:12.0pt; margin-left:21.6pt; line-height:12.0pt; mso-line-height-rule:exactly; mso-pagination:widow-orphan; tab-stops:21.6pt 43.2pt 64.8pt 86.4pt 108.0pt 129.6pt 151.2pt 172.8pt 194.4pt 216.0pt 237.6pt 259.2pt 280.8pt 302.4pt 324.0pt 345.6pt 367.2pt 388.8pt 410.4pt 432.0pt 16.0cm 475.2pt 496.8pt; font-size:12.0pt; font-family:"Courier New","serif"; mso-fareast-font-family:Batang; mso-bidi-font-family:"Courier New";} p.RFCText, li.RFCText, div.RFCText {mso-style-name:"RFC Text"; mso-style-priority:99; mso-style-unhide:no; mso-style-link:"RFC Text Char"; margin-top:0cm; margin-right:0cm; margin-bottom:0cm; margin-left:21.6pt; margin-bottom:.0001pt; line-height:12.0pt; mso-line-height-rule:exactly; mso-pagination:widow-orphan; font-size:12.0pt; mso-bidi-font-size:10.0pt; font-family:"Courier New","serif"; mso-fareast-font-family:"Times New Roman"; mso-bidi-font-family:"Times New Roman";} span.RFCTextChar {mso-style-name:"RFC Text Char"; mso-style-priority:99; mso-style-unhide:no; mso-style-locked:yes; mso-style-link:"RFC Text"; mso-ansi-font-size:12.0pt; font-family:"Courier New","serif"; mso-ascii-font-family:"Courier New"; mso-fareast-font-family:"Times New Roman"; mso-hansi-font-family:"Courier New";} .MsoChpDefault {mso-style-type:export-only; mso-default-props:yes; font-size:10.0pt; mso-ansi-font-size:10.0pt; mso-bidi-font-size:10.0pt; mso-fareast-font-family:"MS Mincho";} <at> page WordSection1 {size:612.0pt 792.0pt; margin:72.0pt 72.0pt 72.0pt 72.0pt; mso-header-margin:36.0pt; mso-footer-margin:36.0pt; mso-paper-source:0;} div.WordSection1 {page:WordSection1;} -->


<Claise, et. Al> Expires January 6, 2012 [Page 24] Internet-Draft <Protocol for IPFIX Mediations> July 2011 4.2. originalExporterIPv6Address Description: The IPv6 address used by the Exporting Process on the Original Exporter. This is used by the IPFIX Mediator Exporting Process to identify the Original Exporter. Abstract Data Type: ipv6Address ElementId: TBD2 Status: Proposed

Add "Semantics: identifier" for consistency with similar fields in the IANA IPFIX registry.


4.3. originalObservationDomainId Description: An identifier of the Observation Domain on the Original Exporter, where the metered IP packets are observed. This is used by the IPFIX Mediator Exporting Process to identify an Observation Domain as received from the Original Exporter. Abstract Data Type: unsigned32 ElementId: TBD3 Status: Proposed

Add "Semantics: identifier" for consistency with #149 in the IANA IPFIX registry.


5. Security Considerations The same security considerations as for the IPFIX Protocol [RFC5101] apply. As they act as both IPFIX Collecting Processes and Exporting Processes, the Security Considerations for IPFIX [RFC5101] apply

s/IPFIX/The IPFIX Protocol/
done.


as well to Mediators. The Security Considerations for IPFIX

s/apply as well/also apply/
Done.


Files [RFC5655] apply as well to IPFIX Mediators that write

s/apply as well/also apply/
Done.


IPFIX Files or use them for internal storage. However, there are a few specific considerations that IPFIX Mediator implementations must take into account in addition.

s/must take into account in addition/must also take into account/
done.


By design, IPFIX Mediators are "men-in-the-middle": they intercede in the communication between an Original Exporter (or another upstream Mediator) and a downstream Collecting Process. This has two important implications for the level of <Claise, et. Al> Expires January 6, 2012 [Page 25] Internet-Draft <Protocol for IPFIX Mediations> July 2011 confidentiality provided across an IPFIX Mediator, and the ability to protect data integrity and Original Exporter authenticity across a Mediator. These are addressed in more detail in the Security Considerations for Mediators in [IPFIX- MED-FMWK]. Note that, while Mediators can use the exporterCertificate and collectorCertificate Information Elements defined in [RFC5655] as described in section 9.3 of [IPFIX-MED-FMWK] to export information about X.509 identities in upstream TLS-protected Transport Sessions, this mechanism cannot be used to provide true end-to-end assertions about a chain of IPFIX Mediators: any Mediator in the chain can simply falsify the information about upstream Transport Sessions In situations where information about the chain of mediation is important, it must be determined out of band. 6. IANA Considerations This document specifies three new IPFIX Information Elements: the applicationDescription, applicationTag and the applicationName. New Information Elements to be added to the IPFIX Information Element registry at [IANA-IPFIX] are listed below. EDITOR'S NOTE: the XML specification in Appendix A must be updated with the elementID values allocated, i.e. TBD1, TBD2, and TDB3,

s/elementID/elementId/

s/TDB/TBD/
Done.

The Appendix will be orphaned when this note is removed. So say something like, "XML specifications of these elements can be found in Appendix A".
Done.


must be replaced. 6.1. originalExporterIPv4Address Name: originalExporterIPv4Address Description: The IPv4 address used by the Exporting Process on the Original Exporter. This is used by an IPFIX Mediator Exporting Process to identify the Original Exporter. Abstract Data Type: ipv4Address Data Type Semantics: identifier ElementId: TBD1 Status: current <Claise, et. Al> Expires January 6, 2012 [Page 26] Internet-Draft <Protocol for IPFIX Mediations> July 2011 6.2. originalExporterIPv6Address Name: originalExporterIPv6Address Description: The IPv6 address used by the Exporting Process on the Original Exporter. This is used by the IPFIX Mediator Exporting Process to identify the Original Exporter. Abstract Data Type: ipv6Address Data Type Semantics: identifier ElementId: TBD2 Status: current 6.3. originalObservationDomainId Name: originalObservationDomainId Description: An identifier of the Observation Domain on the Original Exporter, where the metered IP packets are observed. This is used by the IPFIX Mediator Exporting Process to identify an Observation Domain as received from the Original Exporter. Abstract Data Type: unsigned32 Data Type Semantics: identifier ElementId: TBD3 Status: current 7. References 7.1. Normative References [RFC2119] S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, BCP 14, RFC 2119, March 1997 [RFC3758] Stewart, R., Ramalho, M, Xie, Q., Tuexen, M., and P. Conrad, "Stream Control Transmission Protocol (SCTP), Partial Reliability Extension", May 2004 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, September 2007. [RFC5101] Claise, B., Ed., "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information", RFC 5101, January 2008. [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. Meyer, "Information Model for IP Flow Information Export", RFC 5102, January 2008. <Claise, et. Al> Expires January 6, 2012 [Page 27] Internet-Draft <Protocol for IPFIX Mediations> July 2011 [RFC5655] Trammell, B., Boschi, E., Mark, L., Zseby, T., and A. Wagner, "Specification of the IP Flow Information Export (IPFIX) File Format", RFC 5655, October 2009. [RFC5815] Dietz, T., Kobayashi, A., Claise, B., and G. Muenz, "Definitions of Managed Objects for IP Flow Information Export", RFC 5815, April 2010. [IPFIX-MED-FLOWSEL] D'antonio, S., Zseby, T., Henke, C. and L. Peluso, "Flow Selection Techniques", draft-ietf-ipfix- flow-selection-tech-06.txt, Internet-Draft work in progress, May 2011. [IPFIX-MED-AGGR] Trammell, B., Boschi, E., A. Wagner, and B. Claise, "Exporting Aggregated Flow Data using the IP Flow Information Export (IPFIX) Protocol", draft- trammell-ipfix-a9n-03.txt, Internet-Draft work in progress, June 2011. [IPFIX-STRUCT] Claise, B., Dhandapani, G., Aitken, P., and S. Yates, "Export of Structured Data in IPFIX", draft- ietf-ipfix-structured-data-06.txt, Internet-Draft work in progress, May 2011. [PSAMP-MIB] Dietz, T., Claise, B., and J. Quittek "Definitions of Managed Objects for Packet Sampling", draft-ietf- ipfix-psamp-mib-03.txt, Internet-Draft work in progress, March 2011. [IPFIX-CONF] Muenz, G., Claise, B., and P. Aitken "Configuration Data Model for IPFIX and PSAMP", draft-ietf-ipfix- configuration-model-09, Internet-Draft work in progress, March 2011. 7.2. Informative References [TCP] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. [UDP] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.

See earlier point: for consistency, you should reference these by their RFC numbers, ie "[RFC793]" and "[RFC768]".
Done.


<Claise, et. Al> Expires January 6, 2012 [Page 28] Internet-Draft <Protocol for IPFIX Mediations> July 2011 [RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, "Requirements for IP Flow Information Export", RFC 3917, October 2004 [RFC3954] Claise, B. (Ed), "Cisco Systems NetFlow Services Export Version 9", RFC 3954, October 2004 [RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek, "Architecture Model for IP Flow Information Export", RFC5470, March 2009 [RFC5472] Zseby, T., Boschi, E., Brownlee, N., and B. Claise, "IP Flow Information Export (IPFIX) Applicability", RFC 5472, March 2009 [RFC5476] Claise, B., Quittek, J., and A. Johnson, "Packet Sampling (PSAMP) Protocol Specifications", RFC 5476, March 2009. [RFC5982] Kobayashi, A. (Ed), Claise, B. (Ed), "P Flow Information Export (IPFIX) Mediation: Problem Statement", RFC 5982, August 2010. [IPFIX-MED-FMWK] Kobayashi, A., Claise, B., Muenz, G., and K. Ishibashi, "IPFIX Mediation: Framework", RFC 6183, April 2011. [RFC6235] Boschi, E., Trammell, B. "IP Flow Anonymization Support", RFC 6235, May 2011. [IANA-IPFIX] http://www.iana.org/assignments/ipfix/ipfix.xhtml 8. Author's Addresses Benoit Claise Cisco Systems, Inc. De Kleetlaan 6a b1 Diegem 1813 Belgium Phone: +32 2 704 5622 Email: bclaise <at> cisco.com Atsushi Kobayashi NTT Information Sharing Platform Laboratories <Claise, et. Al> Expires January 6, 2012 [Page 29] Internet-Draft <Protocol for IPFIX Mediations> July 2011 3-9-11 Midori-cho Musashino-shi, Tokyo 180-8585 Japan Phone: +81-422-59-3978 Email: akoba <at> nttv6.net URI: http://www3.plala.or.jp/akoba/ Brian Trammell ETH Zurich Gloriastrasse 35 8092 Zurich Switzerland Phone: +41 44 632 70 13 EMail: trammell <at> tik.ee.ethz.ch 9. Appendix A. Additions to XML Specification of IPFIX Information Elements

s/9. Appendix A/Appendix A/
Done.

Many thanks again.
Impressive feedback.

Regards, Benoit.


This appendix contains additions to the machine-readable description of the IPFIX information model coded in XML in Appendix A and Appendix B in [RFC5102]. Note that this appendix is of informational nature, while the text in Section 6. (generated from this appendix) is normative. The following field definitions are appended to the IPFIX information model in Appendix A of [RFC5102]. <field name="originalExporterIPv4Address" dataType="ipv4Address" group="config" elementId="TBD1" applicability="all" status="current"> <description> <paragraph> The IPv4 address used by the Exporting Process on the Original Exporter. This is used by an IPFIX Mediator Exporting Process to identify the Original Exporter. </paragraph> </description> </field> <field name="originalExporterIPv6Address" dataType="ipv6Address" group="config" <Claise, et. Al> Expires January 6, 2012 [Page 30] Internet-Draft <Protocol for IPFIX Mediations> July 2011 elementId="TBD2" applicability="all" status="current"> <description> <paragraph> The IPv6 address used by the Exporting Process on the Original Exporter. This is used by the IPFIX Mediator Exporting Process to identify the Original Exporter. </paragraph> </description> </field> <field name="originalObservationDomainId" dataType="unsigned32" group="config" elementId="TBD3" applicability="all" status="current"> <description> <paragraph> An identifier of the Observation Domain on the Original Exporter, where the metered IP packets are observed. This is used by the IPFIX Mediator Exporting Process to identify an Observation Domain as received from the Original Exporter. </paragraph> </description> </field> <Claise, et. Al> Expires January 6, 2012 [Page 31]



_______________________________________________
IPFIX mailing list
IPFIX <at> ietf.org
https://www.ietf.org/mailman/listinfo/ipfix
internet-drafts | 6 Dec 14:44 2011
Picon

[IPFIX] I-D Action: draft-ietf-ipfix-mediation-protocol-00.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item
of the IP Flow Information Export Working Group of the IETF.

	Title           : Specification of the Protocol for IPFIX Mediation
	Author(s)       : Benoit Claise
                          Atsushi Kobayashi
                          Brian Trammell
	Filename        : draft-ietf-ipfix-mediation-protocol-00.txt
	Pages           : 33
	Date            : 2011-12-06

        This document specifies the IP Flow Information Export
        (IPFIX) protocol specific to Mediation.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipfix-mediation-protocol-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipfix-mediation-protocol-00.txt

_______________________________________________
IPFIX mailing list
IPFIX <at> ietf.org
https://www.ietf.org/mailman/listinfo/ipfix

Benoit Claise | 6 Dec 15:52 2011
Picon

Re: [IPFIX] I-D Action: draft-ietf-ipfix-mediation-protocol-00.txt

Dear all,

This version takes into account all the feedback received from Paul 
Aitken (I replied to Paul's email to the list yesterday).
On the top of that, the timestamps issue has been fixed by Brian.
Note that some points, which might require some discussions, have been 
listed in the open issues in the draft.

Regards, Benoit.
> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work
item of the IP Flow Information Export Working Group of the IETF.
>
> 	Title           : Specification of the Protocol for IPFIX Mediation
> 	Author(s)       : Benoit Claise
>                            Atsushi Kobayashi
>                            Brian Trammell
> 	Filename        : draft-ietf-ipfix-mediation-protocol-00.txt
> 	Pages           : 33
> 	Date            : 2011-12-06
>
>          This document specifies the IP Flow Information Export
>          (IPFIX) protocol specific to Mediation.
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-ipfix-mediation-protocol-00.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipfix-mediation-protocol-00.txt
>
> _______________________________________________
> IPFIX mailing list
> IPFIX <at> ietf.org
> https://www.ietf.org/mailman/listinfo/ipfix
>
>

_______________________________________________
IPFIX mailing list
IPFIX <at> ietf.org
https://www.ietf.org/mailman/listinfo/ipfix

Al Morton | 6 Dec 23:33 2011
Picon

[IPFIX] WGLC: draft-ietf-bmwg-ipflow-meth-05

BMWG,
CC: IPFIX WG,

This message begins the *fourth* WG Last call on the draft:

IP Flow Information Accounting and Export Benchmarking Methodology

A URL for this draft is:
http://tools.ietf.org/html/draft-ietf-bmwg-ipflow-meth-05

The Last Call will end on January 1, 2012.

We have discussed this draft in the working group for
over three years and made many improvements.
We have also benefited from review by folks from IPFIX WG.

*We have now looked in detail at comments from the 3rd WGLC
and their resolution, including 5 open issues identified
and resolved on the list.*

I now ask everyone to consider items where they commented earlier,
and make sure that the resolutions are satisfactory (and thanks to
those who did this during the second WGLC).

Please weigh-in on whether or not this Internet-Draft
should be given to the Area Directors and IESG for consideration and
publication as an Informational RFC.  Send your comments
to this list and/or acmorton <at> att.com.

Al
bmwg chair

_______________________________________________
IPFIX mailing list
IPFIX <at> ietf.org
https://www.ietf.org/mailman/listinfo/ipfix

Hendrik Scholz | 7 Dec 17:10 2011

[IPFIX] sip-msg-02 SIP messages and aggregation

Hi!

My main interest is to write a single data record describing an
entire SIP dialog (e.g. a call between two parties) and not
a single SIP message.

Below are numerous points where I feel the current definition
may clash with that use case.

2.1 sipObservationType

There is a 'receiver' and 'sender' metering process type for
metering processes co-located with the SIP entity.
I case I want to aggregate multiple SIP messages into a single
entry what should I set here?
It does make a different whether the monitoring process was
co-located with the device or whether it pass 'mid-point'
(option 3 aka 'passive').

Another way of looking at the sipObservationType would be
'unknown', 'co-located' (aka 'end-point') and 'mid-point'.
This drops the 'sender'/'receiver' differentiation.
Could we extend it to have both bits of information encoded
in the sipObservationType?

2.5. sipFromURI
2.7. sipToURI

Would this include URI parameters?
sample: sip:user:password <at> host:port;uri-parameters?headers

This effectively duplicates the 2.6. sipFromTag and
2.8. sipToTag.

A system may opt to display sipFromURI and sipToURI which
may (rare case I guess) include the password. Often
sip:user <at> host would be enough, although it may be up
to the collector to remove unneeded bits.

2.9 sipCallId

Session-ID as defined in draft-kaplan-dispatch-session-id-03
won't be added for now as it's not a WG item, correct?

2.10. sipResponseStatus

In case multiple SIP messages are aggregated into one record
this should be allowed to hold the 'final response', e.g.
a 408 timeout even multiple callees responded with 486 or
early media (180, 183, ...).

3.1. sipContactURI

In the 'aggregated information' usage scenario there would
be (at least) two Contact URIs, e.g. named sipCallerURI and
sipCalleeURI (or UAS/UAC).

4. Template additions

For an aggregated 'sip session' the template would not only
need the observationTimeMilliseconds IE but also
a start/end time plus an optional PostDialDelay etc.
Essentially everything to calculate the RFC6076 SIP
performance metrics.

Finally we should allow SIPS URIs in the SIP URI fields or
point out that this is not intended.

Should I contribute a separate document with additional
Information Elements needed to describe SIP sessions
and a matching recommended template?

Regards,
 Hendrik

--

-- 
VOIPFUTURE GmbH   Wendenstraße 4   20097 Hamburg   Germany
Phone +49 40 688 900 163    Fax +49 40 688 900 199
Email hendrik.scholz <at> voipfuture.com   Web http://www.voipfuture.com

CEO Jan Bastian
Commercial Court AG Hamburg   HRB 109896
VAT ID DE263738086

_______________________________________________
IPFIX mailing list
IPFIX <at> ietf.org
https://www.ietf.org/mailman/listinfo/ipfix

Hendrik Scholz | 7 Dec 17:16 2011

[IPFIX] RTP media stream template?

Hi!

Is anybody working on a template and related IEs for RTP media streams?
I am happy to contribute and/or author the needed documents.

The use cases for this include active VoIP components which handle
RTP streams and want to provide data records as well as passive
monitoring systems which are build to monitor RTP streams.
IEs include general RTP information (source, destination, codec)
as well as IP transport quality (jitter, packet loss, ..) and
higher-level metrics such as R-Factor and MOS value where available.

The template should allow both data records on entire streams (i.e.
part of calls minutes or even hours long) as well as fixed time slices
such as 10 seconds to allow monitoring with a high granularity.

Regards,
 Hendrik

--

-- 
VOIPFUTURE GmbH   Wendenstraße 4   20097 Hamburg   Germany
Phone +49 40 688 900 163    Fax +49 40 688 900 199
Email hendrik.scholz <at> voipfuture.com   Web http://www.voipfuture.com

CEO Jan Bastian
Commercial Court AG Hamburg   HRB 109896
VAT ID DE263738086

_______________________________________________
IPFIX mailing list
IPFIX <at> ietf.org
https://www.ietf.org/mailman/listinfo/ipfix

Carter Bullard | 7 Dec 17:30 2011

Re: [IPFIX] RTP media stream template?

Hey Hendrik,
Argus has RTP specific flow records, with its own IEs for reporting attributes
and metrics for the media streams.   The argus sensor does RTP discovery
on the fly, generating the extended flow attributes without configuration.

The argus DSRs provide the RTP specific information, such as codec, as
well as jitter, ( adjusting for silence suppression when encountered ), loss
and out of order indications, and the argus-client aggregation deals with
handling both entire streams and fixed/variable time slices, no problem.

Argus is not IPFIX, but you may find the argus approach useful.

http://qosient.com/argus

Carter

Carter Bullard
CEO/President
QoSient, LLC
150 E 57th Street Suite 12D
New York, New York  10022

+1 212 588-9133 Phone
+1 212 588-9134 Fax

On Dec 7, 2011, at 11:16 AM, Hendrik Scholz wrote:

> Hi!
> 
> Is anybody working on a template and related IEs for RTP media streams?
> I am happy to contribute and/or author the needed documents.
> 
> The use cases for this include active VoIP components which handle
> RTP streams and want to provide data records as well as passive
> monitoring systems which are build to monitor RTP streams.
> IEs include general RTP information (source, destination, codec)
> as well as IP transport quality (jitter, packet loss, ..) and
> higher-level metrics such as R-Factor and MOS value where available.
> 
> The template should allow both data records on entire streams (i.e.
> part of calls minutes or even hours long) as well as fixed time slices
> such as 10 seconds to allow monitoring with a high granularity.
> 
> Regards,
> Hendrik
> 
> -- 
> VOIPFUTURE GmbH   Wendenstraße 4   20097 Hamburg   Germany
> Phone +49 40 688 900 163    Fax +49 40 688 900 199
> Email hendrik.scholz <at> voipfuture.com   Web http://www.voipfuture.com
> 
> CEO Jan Bastian
> Commercial Court AG Hamburg   HRB 109896
> VAT ID DE263738086
> 
> _______________________________________________
> IPFIX mailing list
> IPFIX <at> ietf.org
> https://www.ietf.org/mailman/listinfo/ipfix
> 

Attachment (smime.p7s): application/pkcs7-signature, 5901 bytes
_______________________________________________
IPFIX mailing list
IPFIX <at> ietf.org
https://www.ietf.org/mailman/listinfo/ipfix

Gmane