http://blog.gmane.org/gmane.ietf.ipfix hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.ietf.ipfix/4949 <pre>Greetings, all, Following a previous suggestion to update propose we modify the names and definitions of the initiatorOctets(231), responderOctets(232), initiatorPackets(298), and responderPackets(299) as follows, (1) to bring them in line with the naming of other IPFIX Information Elements, (2) to allow them to be used by RFC 5103-compliant biflow Exporting Processes, and (3) to ensure (especially in the case of 298 and 299) that the descriptions are interoperably implemented. I think the proposed descriptions reflect the intent of the present descriptions, within the context of RFC 5103 terminology, and should therefore not have any impact on interoperability; I note that the description of IEs 298 and 299 are, however, not decipherable as written, so I may be taking some necessary liberty with my interpretation. Element ID: 232 Name: appOctetDeltaCount Data Type: unsigned64 Semantics: deltaCounter Description: The number of octets, excluding IP header(s) and Layer 4 transport protocol header</pre> Brian Trammell 2013-05-16T15:45:05 http://comments.gmane.org/gmane.ietf.ipfix/4944 <pre>Biggest Fake Conference in Computer Science We are researchers from different parts of the world and conducted a study on the world’s biggest bogus computer science conference WORLDCOMP ( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia from University of Georgia, USA. We submitted a fake paper to WORLDCOMP 2011 and again (the same paper with a modified title) to WORLDCOMP 2012. This paper had numerous fundamental mistakes. Sample statements from that paper include: (1). Binary logic is fuzzy logic and vice versa (2). Pascal developed fuzzy logic (3). Object oriented languages do not exhibit any polymorphism or inheritance (4). TCP and IP are synonyms and are part of OSI model (5). Distributed systems deal with only one computer (6). Laptop is an example for a super computer (7). Operating system is an example for computer hardware Also, our paper did not express any conceptual meaning. However, it was accepted both the times without any modifications (and without</pre> johnsonhammond2< at >hushmail.com 2013-04-27T16:49:12 http://comments.gmane.org/gmane.ietf.ipfix/4940 <pre> 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 : Flow Selection Techniques Author(s) : Salvatore D'Antonio Tanja Zseby Christian Henke Lorenzo Peluso Filename : draft-ietf-ipfix-flow-selection-tech-16.txt Pages : 32 Date : 2013-04-20 Abstract: Intermediate Flow Selection Process is the process of selecting a subset of Flows from all observed Flows. The Intermediate Flow Selection Process may be located at an IPFIX Exporter, Collector, or within an IPFIX Mediator. It reduces the effort of post-processing Flow data and transferring Flow Records. This document describes motivations for using the Intermediate Flow Selection process and presents Intermediate Flow Selection techniques. It provides an information model for configuring </pre> internet-drafts< at >ietf.org 2013-04-20T23:41:37 http://comments.gmane.org/gmane.ietf.ipfix/4939 <pre> The IESG has received a request from the IP Flow Information Export WG (ipfix) to consider the following document: - 'Specification of the IP Flow Information eXport (IPFIX) Protocol for the Exchange of Flow Information' &lt;draft-ietf-ipfix-protocol-rfc5101bis-06.txt&gt; as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf&lt; at &gt;ietf.org mailing lists by 2013-05-01. Exceptionally, comments may be sent to iesg&lt; at &gt;ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies the IP Flow Information Export (IPFIX) protocol that serves for transmitting Traffic Flow information over the network. In order to transmit Traffic Flow information from an Exporting Process to a Collecting Process, a common representation of flow data and a standard means of communicating them is required. This document describes ho</pre> The IESG 2013-04-17T16:36:14 http://comments.gmane.org/gmane.ietf.ipfix/4938 <pre> The IESG has received a request from the IP Flow Information Export WG (ipfix) to consider the following document: - 'Specification of the IP Flow Information eXport (IPFIX) Protocol for the Exchange of Flow Information' &lt;draft-ietf-ipfix-protocol-rfc5101bis-06.txt&gt; as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf&lt; at &gt;ietf.org mailing lists by 2013-05-01. Exceptionally, comments may be sent to iesg&lt; at &gt;ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies the IP Flow Information Export (IPFIX) protocol that serves for transmitting Traffic Flow information over the network. In order to transmit Traffic Flow information from an Exporting Process to a Collecting Process, a common representation of flow data and a standard means of communicating them is required. This document describes ho</pre> The IESG 2013-04-17T16:36:14 http://comments.gmane.org/gmane.ietf.ipfix/4933 <pre>Greetings, all, Following discussion on the ipfix mailing list and review by the ie-doctors, IE 138 in the IANA registry, observationPointId, has been updated to change the data type from unsigned32 to unsigned64. Best regards, Brian (on behalf of the ie-doctors) _______________________________________________ IPFIX mailing list IPFIX&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/ipfix </pre> Brian Trammell 2013-04-11T01:24:27 http://comments.gmane.org/gmane.ietf.ipfix/4927 <pre> 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 : Flow Selection Techniques Author(s) : Salvatore D'Antonio Tanja Zseby Christian Henke Lorenzo Peluso Filename : draft-ietf-ipfix-flow-selection-tech-15.txt Pages : 32 Date : 2013-04-09 Abstract: Intermediate Flow Selection Process is the process of selecting a subset of Flows from all observed Flows. The Intermediate Flow Selection Process may be located at an IPFIX Exporter, Collector, or within an IPFIX Mediator. It reduces the effort of post-processing Flow data and transferring Flow Records. This document describes motivations for using the Intermediate Flow Selection process and presents Intermediate Flow Selection techniques. It provides an information model for configuring </pre> internet-drafts< at >ietf.org 2013-04-09T14:47:22 http://comments.gmane.org/gmane.ietf.ipfix/4923 <pre>Hi Benoit, et al., just a quick question for clarification, would expect that this topic was already discussed by the IPFIX community in the past: The IPFIX registry only lists the RTP SN (RFC 3550) element: http://www.iana.org/assignments/ipfix/ipfix.xml =&gt; rtpSequenceNumber I'm wondering about support of more RTP-specific elements, which would be e.g. required for more fine-granular identification of RTP/RTCP (sub-flows)? Such as support of a) RTP: - RTP PT (payload type)| RTCP PT (packet type) - RTP SSRC - RTP CSCR(s) b) RTCP basic reports: - RTCP SDES CNAME - etc c) RTCP extension reports (RFC 3611, XRBLOCK): - RTCP XR BT - etc Looks odd that the IANA registry just provides the RTP SN, because the SSRC or/and CNAME might be much more interesting for traffic identification purposes. Hm? Regards, Albrecht PS I've noticed the " draft-scholz-ipfix-rtp-audio-quality" proposal. Prime purpose is (in my understanding) the export of LOCAL measurements, e.g. according RTCP XR BT=7 or other RTP applic</pre> Schwarz, Albrecht (Albrecht 2013-04-09T09:57:28 http://comments.gmane.org/gmane.ietf.ipfix/4906 <pre>Dear IPFIX experts, From RFC 6728, 1. Section 4.3.2 o Is there a way to periodically export the flows if we are using a TimeoutCache or NaturalCache ? 2. Suppose we want to populate the cache only with long-lived large flows (see Note1 below for data model definitions) o One way to achieve this would be to have a selection process, using a unique observation domain, which filters the long-lived large flows. Are any other better ways ? 3. Continuing from 3) - suppose we want to sample the other flows (not the long-lived large flows) o Is there a way to not include the long-lived large flows in the selection process ? Note 1: - observationInterval: The minimum time interval to observe a flow for performing further processing of the flow. Unit is in seconds. - bandwidthThreshold: The minimum bandwidth of the flow during the observation interval for declaring the flow a long-lived large flow. Unit is in Mbps. For example, a flow which is at or above 10 Mbps (</pre> ramki Krishnan 2013-03-27T17:40:19 http://comments.gmane.org/gmane.ietf.ipfix/4904 <pre>Greetings, all, During discussions concerning requests for changes to existing Information Elements from consistency on the ie-doctors list, Paul Aitken noted that the definition of "octetArray" (3.1.13) refers to "strings" of octets and the definition of string (3.1.14) refers to "strings" of characters. This could be read as confusingly circular; the correct terminology would would be "sequences". This seems like an editorial change to me, and as the document is still in the RFC Editor queue, I'd like to send an RFC Editor note up with the following change for clarity: OLD: 3.1.13. octetArray The type "octetArray" represents a finite-length string of octets. 3.1.14. string The type "string" represents a finite-length string of valid characters from the Unicode coded character set [ISO.10646]. NEW: 3.1.13. octetArray The type "octetArray" represents a finite-length sequence of octets. 3.1.14. string The type "string" represents a finite-length sequence of valid characte</pre> Brian Trammell 2013-03-25T20:44:44 http://comments.gmane.org/gmane.ietf.ipfix/4896 <pre>Please consider the wording of the paragraph on Sequence Numbers in Section 3.1. Incremental sequence counter modulo 2^32 of all IPFIX Data Records sent in the current stream from the current Observation Domain by the Exporting Process. Each SCTP Stream counts sequence numbers separately, while all messages in a TCP connection or UDP transport session are considered to be part of the same stream. The phrase I have put in italics is depended on Transport protocol. Section 10.3.2 Reliability says: In the case of UDP, the IPFIX Sequence Number contains the total number of IPFIX Data Records sent for the UDP Transport Session prior to the receipt of this IPFIX Message This is NOT dependent on the ObservationDomain. Nothing prohibits the Exporting Process from using the same Transport Session for multiple Observation Domains. But in UDP the Sequence number is for the Transport session, whereas in TCP and SCTP each Observation Domain has an independent sequence on t</pre> Steve Nash 2013-03-21T11:45:55 http://comments.gmane.org/gmane.ietf.ipfix/4893 <pre>The following errata report has been submitted for RFC5655, "Specification of the IP Flow Information Export (IPFIX) File Format". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5655&amp;eid=3560 -------------------------------------- Type: Technical Reported by: Paul Aitken &lt;paitken&lt; at &gt;cisco.com&gt; Section: 8.2.11 + .18 Original Text ------------- (none) Corrected Text -------------- Range: The valid range is 0-0. Notes ----- 8.2.11 messageScope requires a value of 0 ("The value of this Information Element MUST be written as 0") but no range is given. The range should say "0-0". (Compare with text in RFC 5102). Similarly for 8.2.18 sessionScope. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. </pre> RFC Errata System 2013-03-20T11:11:56 http://comments.gmane.org/gmane.ietf.ipfix/4892 <pre>The following errata report has been submitted for RFC5655, "Specification of the IP Flow Information Export (IPFIX) File Format". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5655&amp;eid=3559 -------------------------------------- Type: Technical Reported by: Paul Aitken &lt;paitken&lt; at &gt;cisco.com&gt; Section: 8.2.1 Original Text ------------- (none) Corrected Text -------------- Units: milliseconds Notes ----- collectionTimeMilliseconds requires units of milliseconds. Compare with sections 8.2.7 and 8.2.14 in the same document. IANA's IPFIX IE registry requires the corresponding update. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5655 (draft-ietf</pre> RFC Errata System 2013-03-20T11:07:48 http://comments.gmane.org/gmane.ietf.ipfix/4889 <pre> The IESG has received a request from the IP Flow Information Export WG (ipfix) to consider the following document: - 'Flow Selection Techniques' &lt;draft-ietf-ipfix-flow-selection-tech-14.txt&gt; as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf&lt; at &gt;ietf.org mailing lists by 2013-04-01. Exceptionally, comments may be sent to iesg&lt; at &gt;ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Intermediate Flow Selection Process is the process of selecting a subset of Flows from all observed Flows. The Intermediate Flow Selection Process may be located at an IPFIX Exporter, Collector, or within an IPFIX Mediator. It reduces the effort of post-processing Flow data and transferring Flow Records. This document describes motivations for using the Intermediate Flow Selection process and presents Intermediate Flow Selection </pre> The IESG 2013-03-18T16:55:31 http://comments.gmane.org/gmane.ietf.ipfix/4888 <pre> The IESG has received a request from the IP Flow Information Export WG (ipfix) to consider the following document: - 'Flow Selection Techniques' &lt;draft-ietf-ipfix-flow-selection-tech-14.txt&gt; as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf&lt; at &gt;ietf.org mailing lists by 2013-04-01. Exceptionally, comments may be sent to iesg&lt; at &gt;ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Intermediate Flow Selection Process is the process of selecting a subset of Flows from all observed Flows. The Intermediate Flow Selection Process may be located at an IPFIX Exporter, Collector, or within an IPFIX Mediator. It reduces the effort of post-processing Flow data and transferring Flow Records. This document describes motivations for using the Intermediate Flow Selection process and presents Intermediate Flow Selection </pre> The IESG 2013-03-18T16:55:31 http://comments.gmane.org/gmane.ietf.ipfix/4886 <pre> Hi all: Here are the DRAFT minutes, please send me any corrections or improvements. Cheers, Nevil One-para summary: IPFIX WG meeting in Orlando Our three current chartered drafts, Link layer IEs, MIB Variable Export and Mediation Protocol are close to completion. Several possible new work items were discussed: + Extended Field Specifier Fields (EFSF) as a way to handle 'decorators' in Information Elements, e.g. the layer of an mplsLabelSection. + A textual representation for Information Elements, making it easier to use the IPFIX Information Model for flows in text-based environments. + Mechanisms for moving Private Enterprise IEs into the IANA IPFIX IE Registry, so that Collectors can recognise them more easily. These will be discussed further on the IPFIX list. Minutes of the IPFIX meeting at IETF 86 in Orlando About 16 people present, plus 4 on jabber Scribes: Chris Inacio, Nevil Brownlee Meeting chair: Nevil Brownlee Nevil opened the meeting, and gave the IPFIX status updat</pre> Nevil Brownlee 2013-03-15T02:28:19 http://comments.gmane.org/gmane.ietf.ipfix/4885 <pre>Dear Authors, Here's another review of draft-ietf-ipfix-mediation-protocol-04. Overall I'm happy with the shape of this draft; I have no major technical issues. Just some minor ones, and loads of editorial issues. Please find comments inline: Typo, "described". Typo, "or". These definitions imply that OPs belong to the exporter, which is not the case; they belong to the MP or to the IPFIX device. For all the words, I only understood that IFSP is a superset of ISP - and I feel that I missed the point? I know exactly what you're saying here, but others might not. I suggest s/keep/use/. TWM + Template definitions in separate messages must also not be re-ordered. Typo, "authoritative". I can't parse this properly - partly because the comma section is completely parenthesised. What does "substantially the same Data Records" mean? It could be: * the same data records, +/- a field or two. * the same fields, +/- some records. Should "Template" be plural? Typo, "receive</pre> Paul Aitken 2013-03-14T23:37:55 http://comments.gmane.org/gmane.ietf.ipfix/4884 <pre>Brian, Here's a review of draft-trammell-ipfix-text-adt-00. Please find comments inline. Doesn't parse. Remove "and". If the names are to be the (joint?) primary reference for IEs, then IE doctors should review all the IE names to ensure consistency, and define rules for new IE names to ensure that consistency is maintained. Where is "Core Rules" defined? * it's a pointer? RFC5234, sigh: / looks like division, although it's intended as "OR". Consider allowing binary or any arbitrary number base to be used. Can we ever get away from the idea that u8, u16, u32, and u64 are different types? Rather, they're just different size encodings of the same type. (Same comments for this section as for "unsigned" above.) ie, a decimal point with at least zero digits following? Why? The decimal point is only required when there are following digits. Typo, "naturally". RFC5235 ABNF inconsistently uses - as a range indicator while also allowing it in rule names. Should be "5*5" to con</pre> Paul Aitken 2013-03-14T12:17:54 http://comments.gmane.org/gmane.ietf.ipfix/4883 <pre>Dear authors, Please find some review comments inline: These definitions are circular, and inconsistent with the text below. Rather, use the same definitions as below: "Large flow: a long-lived flow which exceeds a certain minimum bandwidth threshold over an observation interval." If large flows are not sampled, then how do we know they're large flows? ie, there seems to be a pre-requisite flow classification step ahead of the sampling. Paraphrasing what I read so far: traffic may be divided into two groups, using techniques to be discussed in s2.1. Since this task is out of scope of the current discussion, our task is trivial: one group can be ignored, while the other group contains all the security threats. So forget about "large" and "small" flows for a moment. I went back a and re-read the above text substituting s/large/safe/ and s/small/dangerous/, which was much more entertaining. This isn't the IPFIX definition of "Flow". In one implementation, perhaps. Per RFC5101, flows a</pre> Paul Aitken 2013-03-14T10:59:32 http://comments.gmane.org/gmane.ietf.ipfix/4882 <pre>Dear all, a virtual room has been reserved on the Meetecho system for the IPFIX WG meeting session. Access to the on-line session (including audio and video streams) will be made available (just a couple of minutes before session start time) at: http://www.meetecho.com/ietf86/ipfix The Meetecho session automatically logs you into the standard IETF jabber room. So, from there, you can have an integrated experience involving all media and allowing you to interact with the room. A tutorial of interactivity features of the tool can be found at: http://www.meetecho.com/ietf86 Cheers, the Meetecho Team This email has been automatically generated by The Meetecho Conferencing System _______________________________________________ IPFIX mailing list IPFIX&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/ipfix </pre> Meetecho Team 2013-03-13T23:31:38 http://comments.gmane.org/gmane.ietf.ipfix/4878 <pre>Dear IPFIX experts, RFC5102 defines two processId IEs: meteringProcessId and exportingProcessId. And we could expect more *ProcessId IEs in future. Are these expected or required to be unique? Do we allow that a single process can both meter and export, therefore they are not unique? What about the case of multiple CPUs, where although the processes are unique, the processIDs happen to be identical? Thanks, P. _______________________________________________ IPFIX mailing list IPFIX&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/ipfix </pre> Paul Aitken 2013-03-13T11:26:38 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.ipfix