[10:40:01] --- jfworld has joined
[10:40:09] --- jfworld has left
[10:57:06] --- J-F has joined
[10:57:38] --- J-F has left
[14:55:51] --- LOGGING STARTED
[15:23:34] --- gerhard has joined
[15:33:55] --- sommer@jabber.cc has joined
[15:37:34] --- dbh2 has joined
[15:42:41] --- juergen has joined
[15:44:20] --- Simon Leinen has joined
[15:45:43] <gerhard> yes
[15:46:03] <Simon Leinen> thanks!
[15:46:08] <juergen> Hi Simon,
[15:46:13] <Simon Leinen> Hi Juergen
[15:46:17] <juergen> MP3 quality is very good.
[15:46:23] <Simon Leinen> Good to hear
[15:46:54] <juergen> I am currently checking the slides on the meeting materials page.
[15:47:02] <juergen> looks like a few are still missing.
[15:47:15] <Simon Leinen> Oops, I thought there already were a lot
[15:47:28] <juergen> ... just a few
[15:53:28] --- histerrier has joined
[15:56:13] --- pjaitken has joined
[15:58:54] <juergen> The slides on the materials server should be upto date and coplete by know ...
[15:59:15] <juergen> ... except for the mediator slides. I am not sure what will be th final order of rpesentation
[16:00:58] <sommer@jabber.cc> I'd like to talk about the IPFIX Flow Aggregation draft first, then about the Mediatior-specific extensions, being the last two slide sets in out 40-minute slot
[16:01:39] <juergen> Can you give me the full list including Kobayashi-san's slides
[16:02:31] <sommer@jabber.cc> IIRC the planned order was "Problem Statement", "Framework", "Aggregation", "Extensions"
[16:03:08] --- eliot.lear has joined
[16:03:19] <eliot.lear> welcome. i will be jabbering for the first hour
[16:03:32] <eliot.lear> simon talking: group to be rechartered
[16:03:52] <eliot.lear> review of documents completed by WG
[16:04:10] <eliot.lear> please review psamp drafts to keep things moving
[16:04:31] <juergen> Thank you Eliot !!!
[16:04:32] <eliot.lear> new version of implementation guidelines that hasn't shown up in the repository
[16:04:36] <eliot.lear> (welcomes)
[16:04:41] --- dbh2 has left
[16:04:53] <eliot.lear> outstanding work item is ipfix-mib
[16:05:03] <eliot.lear> milestone update
[16:05:06] --- kenichi has joined
[16:05:15] <eliot.lear> ipfix testing draft is close to submission
[16:05:25] <eliot.lear> ipfix mib is slipping
[16:05:31] <eliot.lear> new charter:
[16:05:41] <eliot.lear> approved 15 nov by iesg
[16:05:52] <eliot.lear> new and not-so-new work items that require documents
[16:06:17] <eliot.lear> most of what we should do at this meeting would be to look at individual contributions and determine if those are suitable for adoption
[16:07:01] <eliot.lear> when an individual draft becomes a wg draft, the draft loses an author and gains an editor, and change control shifts from author to wg
[16:07:12] <eliot.lear> are these documents ripe for adoption?
[16:07:27] <eliot.lear> do we want to give authors more time before adopting as wg draft?
[16:07:54] <eliot.lear> there will be presentations. then simon will ask who in the room has read the draft, and then whether we should adopt the work
[16:08:15] <eliot.lear> coming back to psamp, on which this work sometimes depends...
[16:08:32] <eliot.lear> new versions are under preparation. the information model is in working group last call.
[16:08:50] <eliot.lear> not enough people have reviewed the psamp information model, and this will block work in ipfix
[16:09:09] <eliot.lear> agenda now
[16:09:26] <eliot.lear> elisa boschi: implementation guidelines
[16:10:15] <juergen> Now also the slides on mediation should be in the right order
[16:10:22] <sommer@jabber.cc> Thanks!
[16:10:34] <eliot.lear> gone through ietf and iesg review
[16:10:36] <eliot.lear> two discusses filed
[16:10:56] <eliot.lear> they've been addressed in the updated version
[16:11:01] <eliot.lear> confirmation of one of these cleared
[16:11:50] <eliot.lear> new paragraph in sctp section
[16:12:08] <eliot.lear> template withdrawal messages as discussed in chicago
[16:12:27] <eliot.lear> transport directorate; UDP is NOT RECOMMENDED
[16:12:59] <eliot.lear> solution: added text in the UDP section to discourage UDP except in specific circumstances
[16:13:17] <eliot.lear> Discuss use of 2119 language in guidelines documents is considered dangerous
[16:13:45] <eliot.lear> lower-casified MUSTs and SHOULDs, and added some text stating that the doc is not normative
[16:13:50] <eliot.lear> other discuss
[16:14:08] <eliot.lear> problems with a paragraph on the maturity of SCTP
[16:14:18] <eliot.lear> removed paragraph in question
[16:14:31] <eliot.lear> other changes are minor
[16:14:33] <eliot.lear> history removed
[16:14:37] <eliot.lear> editorial changes
[16:14:38] <eliot.lear> nits
[16:15:13] <eliot.lear> simon: progressing smoothly. questions?
[16:15:37] <eliot.lear> Paul Aitken: testing
[16:15:59] <eliot.lear> current status
[16:16:07] <eliot.lear> publication requested
[16:16:14] <eliot.lear> thank you to reviewers
[16:16:33] <eliot.lear> main changes were incorrect template records section, due to TCP streaming
[16:16:47] <eliot.lear> simplified intro
[16:16:57] <eliot.lear> several clarifications and and language issues
[16:16:58] --- heycengiz@gmail.com has joined
[16:16:59] <eliot.lear> that's it.
[16:17:01] <eliot.lear> questions?
[16:17:06] --- dromasca has joined
[16:17:23] <eliot.lear> Benoit on the MIB
[16:17:37] <eliot.lear> (open office seems to be booting)
[16:18:28] <eliot.lear> late for the deadline
[16:18:32] <eliot.lear> ipfix-mib posted yesterday
[16:18:48] <eliot.lear> no changes in structure or in ro v rw
[16:18:58] <eliot.lear> added active and timeout in ipfixTemplateTable
[16:19:19] <eliot.lear> removed terminology section and referenced protocol draft
[16:19:23] <eliot.lear> all open issues resolved
[16:19:26] <eliot.lear> what's next?
[16:19:38] <eliot.lear> unless there are more issues, we are ready for wglc
[16:19:40] <eliot.lear> questions?
[16:19:47] --- heycengiz@gmail.com has left
[16:19:55] <eliot.lear> simon: has this been reviewed sufficiently?
[16:20:02] <eliot.lear> benoit: not yet. that should happen in wglc
[16:20:31] <eliot.lear> simon: done with drafts on old charter
[16:20:42] <eliot.lear> now looking at new charter ordered by milestones
[16:20:55] --- dbh2 has joined
[16:20:59] --- heycengiz@gmail.com has joined
[16:21:15] <eliot.lear> file format draft:
[16:21:34] <eliot.lear> Brian Drammel, CERT/NSA
[16:21:48] <eliot.lear> trammel, excuse me
[16:22:18] <eliot.lear> this draft came out of ietf 65, and we've been working on it since, and we think it's ready
[16:23:08] <eliot.lear> why not base a file format on ipfix with templates
[16:23:13] <eliot.lear> treat file system as a transport
[16:23:44] --- heycengiz@gmail.com has left
[16:23:51] --- mbj has joined
[16:23:52] <eliot.lear> removed file format survey.
[16:24:34] <eliot.lear> now discussion about v9 -> ipfix issues
[16:24:35] <eliot.lear> future
[16:24:51] <eliot.lear> aiming for adoption now or soon
[16:24:57] <eliot.lear> and we think we're going to be done
[16:25:14] <eliot.lear> questions:
[16:25:35] <eliot.lear> dan r: aiming for january for last call and then to iesg by january?
[16:25:50] <eliot.lear> yes, jan.
[16:26:01] <juergen> January was intentional
[16:26:25] <eliot.lear> benoit: i have some comments
[16:26:49] <eliot.lear> i was surprised that the collecting process collects into a file
[16:27:29] <eliot.lear> but anything can be a file writer
[16:27:32] <eliot.lear> [speaker agrees]
[16:27:36] <gerhard> IMHO, an exporting process might be a file writer, not a collecting process.
[16:28:04] <eliot.lear> ALL: if you want a comment raised at the MIC prefix your comment with MIC
[16:28:36] <eliot.lear> we would like any ipfix message stream to be a valid file
[16:28:51] <eliot.lear> so that you could use netcat as a poor man's collecting process
[16:29:09] <eliot.lear> if you want to add information, use options records
[16:29:40] <eliot.lear> not explicit in the draft. if we want to do that as a working group, we might want to discuss this over the next six weeks
[16:29:54] <eliot.lear> adds a little overhead, but you have compression
[16:29:55] <pjaitken> Garhard, did you want that point raised at the mic here?
[16:30:08] <eliot.lear> continue on the mailing list
[16:30:15] <eliot.lear> simon: who has read the draft?
[16:30:23] <eliot.lear> O(10)
[16:30:52] <eliot.lear> O(8)
[16:31:01] <eliot.lear> 8 people think it's ready
[16:31:08] <eliot.lear> nobody think it's not
[16:32:11] <eliot.lear> confirm on the mailing list
[16:32:42] <eliot.lear> configuration data model
[16:32:44] <eliot.lear> benoit again
[16:34:18] <eliot.lear> changes: based on rfc3917 requirements and framework and protocol, create a model
[16:34:23] <eliot.lear> received 3 reviews
[16:34:31] <eliot.lear> comments about how to improve text
[16:35:05] <eliot.lear> there was a misunderstanding of the link between the metering process and the cache. new text added.
[16:35:46] <eliot.lear> received request: add direction at observation points (egress and ingress)
[16:35:53] <eliot.lear> don't think both are necessary
[16:36:31] <gerhard> I catched an error on slide 3 of the IPFIX configuration presentation: "must not be supported" => "does not have to be supported", sorry for that
[16:36:39] <eliot.lear> we have AND filters. request for OR
[16:36:59] <eliot.lear> but maybe not necessary. more consensus needed
[16:37:43] <eliot.lear> received request: conf. parameter for packet size and delay caused by export process
[16:38:01] <eliot.lear> recommend vendor specific tag
[16:38:14] <eliot.lear> observationPointId parameter
[16:38:30] <eliot.lear> configuration doesn't have to be supported...
[16:38:43] <eliot.lear> readability
[16:38:54] <eliot.lear> configuration data model
[16:38:59] <eliot.lear> configuration of export process restructure
[16:39:01] <eliot.lear> UML
[16:39:02] <eliot.lear> removed id
[16:39:16] <eliot.lear> open issues
[16:39:20] <eliot.lear> file export
[16:39:27] --- arifumi has joined
[16:39:30] <eliot.lear> we need both a metering and export process
[16:39:40] <eliot.lear> file import
[16:39:58] <eliot.lear> do we need to have a file-based collecting process?
[16:40:19] <eliot.lear> selection process
[16:40:31] <eliot.lear> check if current configuration corresponds to PSAMP
[16:40:41] <eliot.lear> should we say netconf is a must?
[16:40:48] <eliot.lear> recommend but no mandate
[16:40:55] <eliot.lear> keep independent
[16:41:02] <eliot.lear> next steps
[16:41:08] <eliot.lear> we will submit new draft by christmas
[16:41:17] <eliot.lear> depending on your feedback will make it wg or individual
[16:41:19] <eliot.lear> questions?
[16:41:23] <eliot.lear> who has read this draft?
[16:41:38] <eliot.lear> not reviewed widely
[16:41:50] <eliot.lear> doesn't make sense to ask for adoption
[16:41:57] <eliot.lear> we will take it to the mailing list
[16:42:06] <eliot.lear> more reviewers needed!
[16:42:37] <eliot.lear> netconf we had planned a netconf session but has been canceled. other wgs that have configuraiton needs can still stop by
[16:43:17] <eliot.lear> next session
[16:43:24] <eliot.lear> sorry- next presentation
[16:43:35] <eliot.lear> exporting type information for ipfix information elements
[16:43:39] <eliot.lear> elisa boschi
[16:44:19] <eliot.lear> this is an improved version with a changed name, thus -00
[16:44:39] <eliot.lear> ipfix doesn't provide mechanism to represent information model properties
[16:45:14] <eliot.lear> interoperability issue
[16:45:35] <eliot.lear> history discussion
[16:46:02] <eliot.lear> lack of type information in 2005 idenitified as enterprise specifci IE interoperability issue
[16:46:11] <eliot.lear> in prague, had an initial solution
[16:46:55] <eliot.lear> problem not limited to file
[16:47:01] <eliot.lear> chicago we extended it
[16:47:12] <eliot.lear> more complete inline representation
[16:48:11] <eliot.lear> representing ifnormation inline allows for self description
[16:48:22] <eliot.lear> datatype, semantics (counter, id, flags)
[16:48:23] <eliot.lear> units
[16:48:24] <eliot.lear> ranges
[16:48:27] <eliot.lear> name and description
[16:49:16] <eliot.lear> examples
[16:49:22] <eliot.lear> initial and union TCP flags
[16:49:31] <eliot.lear> with type export e can display names
[16:49:38] <eliot.lear> template example now up
[16:49:52] <eliot.lear> options template example now up
[16:50:21] <eliot.lear> options now up
[16:50:27] <eliot.lear> future work:
[16:50:39] <eliot.lear> submit ietf -00 rev after vc ietf
[16:50:46] <eliot.lear> submission of final draft by june
[16:51:03] <eliot.lear> questions?
[16:51:15] <eliot.lear> paul aitken:
[16:51:37] <eliot.lear> would this have a negative impact by presisting enterprise elements and not drive interoperability?
[16:52:32] <eliot.lear> we're not RECOMMENDing use of enterprise specific elements
[16:52:55] <eliot.lear> trammel: rephrasing, "we should keep enterprise elements broken to encourage standardization?"
[16:54:06] <eliot.lear> at least names will match so that you can correlate between old and new elements
[16:54:16] <eliot.lear> paul:
[16:55:13] <eliot.lear> while this is a good idea, and covers a lot of experimental situations, when you actually want to sell products we should encourage you to use standardized information elements
[16:55:14] <eliot.lear> dan:
[16:56:27] <eliot.lear> this looks like a kind of set of rules that data modelling language for exporting types information, and some perhaps some heuristics and semantics. yes, we want to encourage people to use existing types, but we cannot expect someone who wants to ship something to wait 1 or 1.5 years. so if we don't do something here, people will do their own thing
[16:56:50] --- lhotka has joined
[16:56:50] <eliot.lear> my question is whether we have sorted what it would take to make the transition from private to public easier
[16:57:12] <eliot.lear> for the smi, you can reroot an enterprise mib and make it standard
[16:57:17] <eliot.lear> would the process be the same?
[16:57:37] <eliot.lear> presentor:
[16:57:47] <eliot.lear> it would be easy to use this method and would be compatable.
[16:57:50] <eliot.lear> dan:
[16:58:29] <eliot.lear> there may be a need to put some text to clarify definition of exporting types doesn't mean to discourage standardization of types
[16:58:33] <eliot.lear> brian trammel: what dan said
[16:58:52] <eliot.lear> is mapping in scope?
[16:59:30] <eliot.lear> there is a danger about direct mappings
[17:00:14] <eliot.lear> benoit:
[17:00:48] <eliot.lear> do you have guidelines on preventing people from doing stupid things as far as types are concerned?
[17:01:06] <eliot.lear> presentor: we probably need some more text
[17:01:32] <eliot.lear> simon: we need to move on
[17:01:44] <eliot.lear> eliot: i must stop jabbering.
[17:02:03] --- eliot.lear has left
[17:02:36] <pjaitken> About 7 people read the draft
[17:02:41] <pjaitken> 5 or 6 in favour of adopting
[17:02:47] <pjaitken> no body against
[17:03:03] <pjaitken> Benoit: per stream reporting
[17:03:41] <pjaitken> Export template + data record in a single stream
[17:03:46] <pjaitken> Advantages:
[17:04:19] <pjaitken> data record loss per stream
[17:04:31] <pjaitken> transmission order is maintained
[17:04:54] <pjaitken> Not enough streams?
[17:05:21] <pjaitken> there's a way to add streams to an SCTP association
[17:05:32] <pjaitken> else, use stream 0
[17:05:57] <pjaitken> But lose the ability to know record loss per template
[17:06:02] <pjaitken> Problem:
[17:06:19] <pjaitken> template in multiple streams
[17:06:58] <pjaitken> Not solved here; limitation of IPFIX.
[17:07:21] <pjaitken> (slide 6)
[17:08:03] <pjaitken> Would have to include stream in template scope to solve this
[17:08:13] <pjaitken> wouldn't be backwards compatible
[17:08:37] <juergen> I do not get audio anymore. Do others still get it?
[17:08:54] <pjaitken> template withdrawal message must be sent in the right stream
[17:09:14] <gerhard> My stream is also dead
[17:09:37] <pjaitken> should we say redefinition is not encouraged?
[17:09:51] <pjaitken> Audio check
[17:09:58] <pjaitken> Can you hear?
[17:10:11] <juergen> no
[17:10:14] <pjaitken> Should we have a must?
[17:10:17] <pjaitken> (slide 7)
[17:10:26] <juergen> I cannot get any stream of any ongoing IETF session
[17:10:37] <pjaitken> Encourage everyone to review and provide feedback
[17:10:44] <pjaitken> Open issues
[17:10:53] <pjaitken> withdrawl message: should it be a must?
[17:10:55] <gerhard> stream is back again
[17:11:17] <pjaitken> On the CP side, what to do?
[17:11:42] <pjaitken> (end)
[17:11:54] <pjaitken> Complete rewrite of the draft. Advise you to read it. Thanks.
[17:12:14] <pjaitken> 2 people have read it.
[17:12:42] <pjaitken> Simon: close to new charter work item
[17:13:05] <pjaitken> so we have to do something in this area.
[17:13:31] <pjaitken> 1 person says ready for adoption as WG item = not enough. take it to the mailing list.
[17:13:52] <pjaitken> Next 40 mins for mediation devices
[17:14:04] <pjaitken> charter: problem statement and framework document.
[17:14:58] <pjaitken> There are 4 drafts for 40 mins.
[17:15:01] <juergen> Also my audio stream is back
[17:15:10] <pjaitken> Problem statement, mediator, and 2 regarding aggregations.
[17:15:37] --- jhs has joined
[17:15:43] <pjaitken> Haruhiko Nishida presenting, I think.
[17:15:53] <pjaitken> Mediation problem statement
[17:16:17] --- jhs has left
[17:16:26] <pjaitken> WG suggested making problem statement an individual draft
[17:16:43] <pjaitken> slide 2
[17:16:54] <pjaitken> large ISP network example
[17:17:34] <pjaitken> left hand side: it's a BIG network
[17:17:57] <pjaitken> Using MPLS in backbone.
[17:18:13] <pjaitken> Backbone consists of several different kinds of network
[17:18:24] <pjaitken> RFC 1918 addresses in use.
[17:18:55] <pjaitken> Too much traffic for one collector.
[17:19:01] <pjaitken> slide 3
[17:19:18] <pjaitken> Flow measurement is much better than SNMP counters
[17:20:01] <pjaitken> sampling used to reduce CPU and memory in routers
[17:20:29] <pjaitken> net getting flow data from all routers, just selected few.
[17:20:36] <pjaitken> net -> not
[17:20:45] <pjaitken> challenge is scalability
[17:21:01] <pjaitken> slide 4
[17:21:07] <pjaitken> approach for scalability
[17:21:42] <pjaitken> hierarchical arrangement of concentrators
[17:22:41] <pjaitken> problem: sampling rate, algorithm, observation point: no clear definition how to deal with these in aggregations
[17:22:46] <pjaitken> slide 5
[17:22:54] <pjaitken> how can we distinguish networks?
[17:23:18] <pjaitken> VPN and internet share backbone, but maybe need different measurements.
[17:23:32] <pjaitken> Currently no way to distinguish and send to different collectors.
[17:23:41] <pjaitken> slide 6
[17:23:46] <pjaitken> flow classifiers
[17:24:08] <pjaitken> which flow records belong to which network? And go to which colllector?
[17:24:20] <pjaitken> may help scalability issue.
[17:24:26] <pjaitken> slide 7
[17:24:28] <pjaitken> conclusion
[17:24:37] <pjaitken> concentrator will help; it's good for big network
[17:24:55] <pjaitken> need consensus on how aggregation will work.
[17:25:15] <pjaitken> classifier isn't included in concentrator.
[17:25:25] <pjaitken> need more functionality in intermediate node.
[17:25:28] <pjaitken> slide 8
[17:25:30] <pjaitken> next step
[17:26:13] <pjaitken> exchanging data and anonymisation may be done in intermediate node.
[17:26:14] <pjaitken> Q?
[17:26:19] <pjaitken> Ralf Wolter
[17:26:29] <pjaitken> Why might concentrator lose some data?
[17:26:39] <pjaitken> -> there is no clear definition of aggregation.
[17:26:46] <pjaitken> back to slide 4
[17:26:55] <pjaitken> routers send info
[17:27:08] <pjaitken> if we aggregate flows in this pop
[17:27:14] <pjaitken> we lose info in the concentrator
[17:27:21] <pjaitken> Ralf: lose info, but not flows.
[17:27:37] <pjaitken> treatment is not yet well defined
[17:27:45] <pjaitken> RW: 2nd Q on slide 7
[17:28:25] <pjaitken> something in between exporter and collector
[17:28:27] <pjaitken> Dan:
[17:28:52] <pjaitken> I'm a little bit concerned. I see this work kind of... Previous presentations I understood scalability and searching for solution
[17:29:13] <pjaitken> Now, try to go beyond solving scalability problem and become something more complex.
[17:29:28] <pjaitken> Range of functions expand beyond initial requiremts I understood from this work.
[17:29:51] <pjaitken> Looking at this diagram here, you seem to put more functionality into... not a concentrator, but...
[17:29:57] <pjaitken> SL: we're talking about mediators
[17:30:15] <pjaitken> DR: I'm losing focus, wondering whether more useful to focus on issue of scalability.
[17:30:30] <pjaitken> Other things being dealt with don't need solved today
[17:30:50] --- histerrier has left
[17:30:57] <pjaitken> SL: hat off, as an operator, we do this, this matches what we've been doing for years
[17:31:20] <pjaitken> I can think of things that would be useful extenstions to the protocol to make explict these kinds of devices
[17:31:26] <pjaitken> As an operator I can relate to this.
[17:31:34] <pjaitken> DR: it's different to the original scope of the work, right?
[17:31:44] <pjaitken> You're doing it today - so why do you need a standard for this?
[17:31:48] <gerhard> MIC: Problem 2 seems to be a limitation of current IPFIX implementations. Apart from that, is it really a standardization issue?
[17:31:55] <pjaitken> SL: good question.
[17:32:12] <pjaitken> People have specific types, so data is less self contained.
[17:32:13] <sommer@jabber.cc> queueing
[17:32:20] <pjaitken> I have to explain to my customers how to use the data.
[17:32:31] <pjaitken> A standard way of marking hte mediator output is needed.
[17:32:39] <pjaitken> DR: why does it need to be done in IPFIX?
[17:33:07] <pjaitken> DR: ...
[17:33:18] <pjaitken> Not everything needs to be a standard.
[17:34:08] <pjaitken> presenter: flow can be sent to multiple collectors
[17:34:13] <pjaitken> collectors can do filtering
[17:34:21] <pjaitken> sometimes exporters also have filtering
[17:34:36] <gerhard> ok, my question is answered
[17:34:37] <pjaitken> So it can do same thing with current spec. But not too good.
[17:35:25] <pjaitken> SL: mediation problem statement for Jan.
[17:36:28] <pjaitken> SL: framework not in charter?
[17:37:04] <gerhard> here
[17:37:04] <pjaitken> 4 people have read it
[17:37:33] <pjaitken> 1 person says should be WG item
[17:38:11] <pjaitken> next: mediation framework.
[17:38:15] <pjaitken> SL: time is short
[17:38:29] <pjaitken> Kobayashi-san.
[17:39:07] <pjaitken> (Technical problem with the slides)
[17:39:11] <pjaitken> slide 2
[17:39:14] <pjaitken> updates
[17:39:26] <pjaitken> slide 3
[17:39:32] <pjaitken> what is mediator?
[17:40:46] <pjaitken> slide 4
[17:40:54] <pjaitken> internal component model
[17:41:54] <pjaitken> slide 6
[17:42:01] <pjaitken> obs domain ID management
[17:43:00] <pjaitken> slide 7
[17:43:03] <pjaitken> next step
[17:43:17] <pjaitken> slide 8
[17:43:32] <pjaitken> more next steps
[17:43:54] <pjaitken> slide 9
[17:44:00] <pjaitken> more and more next steps
[17:44:34] <pjaitken> slide 10
[17:44:39] <pjaitken> talk about CPAN
[17:44:43] <pjaitken> flow mediation
[17:45:17] <pjaitken> (ends)
[17:45:35] <pjaitken> no questions.
[17:46:24] <pjaitken> Christoph Sommer
[17:46:29] <pjaitken> Aggregation draft
[17:46:42] <pjaitken> dressler-ipfix-aggregation-04
[17:46:55] <pjaitken> slide 2, aggregation steps
[17:47:11] <pjaitken> slide 5
[17:47:15] <pjaitken> flow selection
[17:47:28] --- arifumi has left: Disconnected
[17:47:48] <pjaitken> slide 6
[17:47:53] <pjaitken> skipped 6, 7
[17:47:54] <pjaitken> slide 8
[17:47:59] <pjaitken> deriving templates
[17:48:34] <pjaitken> slide 9
[17:48:37] <pjaitken> example
[17:49:24] <pjaitken> slide 10
[17:49:28] <pjaitken> slide 11
[17:49:49] <pjaitken> slide 13
[17:49:51] <pjaitken> open issues
[17:49:59] <pjaitken> (ends)
[17:50:11] <pjaitken> next slides: extensions to IPFIX data model and protocol.
[17:50:25] <pjaitken> slide 3
[17:50:29] <pjaitken> rich template set
[17:50:45] <pjaitken> slide 4
[17:51:16] <pjaitken> rich template means don't have to use common properties
[17:51:20] <pjaitken> slide 5
[17:51:25] <pjaitken> ipv4Network
[17:52:18] <pjaitken> slide 6
[17:52:22] <pjaitken> portRanges
[17:52:54] <pjaitken> slide 7
[17:52:59] <pjaitken> excludedPropertiesID
[17:53:53] <pjaitken> slide 8
[17:54:01] <pjaitken> precedingRulePropertiesId
[17:54:21] <pjaitken> slide 9
[17:54:22] <pjaitken> summary
[17:54:55] <pjaitken> (ends)
[17:55:05] <pjaitken> Brian Trammel:
[17:55:13] <juergen> my audio is dead again
[17:55:18] <pjaitken> para 2 of charter prevents us from changing template
[17:55:30] <pjaitken> and new standards action for new data types
[17:55:48] <pjaitken> SL: two more presentations, only 4 mins
[17:56:10] <pjaitken> Hitoshi-san
[17:56:15] <pjaitken> Order of Info Elements
[17:56:30] <pjaitken> Page: Current 03 draft
[17:57:10] <pjaitken> next slide: ideas of new oeder and inceasing perfomance
[17:58:05] --- mbj has left
[17:58:11] <pjaitken> slide: example
[17:58:58] --- lhotka has left
[17:59:04] <pjaitken> next slide: suggested order
[17:59:48] <pjaitken> (ends)
[18:00:03] <pjaitken> Kobayashi-san, multicast measurements
[18:00:28] <pjaitken> Slide 1 - motivation
[18:00:37] <pjaitken> slide 2
[18:00:57] <pjaitken> slide 3 - operational requirements
[18:01:14] <pjaitken> slide 4 - study results
[18:01:44] <pjaitken> (is audio still down?)
[18:02:05] <pjaitken> slide 5: problems
[18:02:31] <pjaitken> slide 6: problem 2
[18:02:54] <gerhard> back again
[18:03:13] <pjaitken> slide 7 - conclusion
[18:03:14] <gerhard> but only for a second :(
[18:03:36] --- kenichi has left
[18:03:39] <pjaitken> (ends)
[18:03:46] <pjaitken> SL: questions?
[18:03:51] <pjaitken> We're over time
[18:03:53] <pjaitken> thanks for coming.
[18:04:03] <pjaitken> (meeting ends)
[18:04:27] --- dbh2 has left
[18:04:54] --- dromasca has left
[18:05:09] --- Simon Leinen has left
[18:05:09] --- sommer@jabber.cc has left
[18:05:12] <pjaitken> Bye!
[18:05:16] --- pjaitken has left
[18:07:10] --- juergen has left
[18:07:22] --- gerhard has left
[18:27:38] --- dbh2 has joined
[18:43:06] --- juergen has joined
[18:43:18] --- juergen has left
[19:33:56] --- dbh2 has left