[12:02:03] --- LOGGING STARTED
[12:37:18] --- miaofy has joined
[12:37:28] --- miaofy has left
[12:50:19] --- irino has joined
[12:50:42] --- irino has left
[12:51:05] --- irino has joined
[12:56:48] --- nevil has joined
[12:58:24] --- pjaitken has joined
[12:58:45] --- miaofy has joined
[13:00:03] <nevil> hi paul :-)
[13:00:12] <pjaitken> Hi Nevil!
[13:00:32] <pjaitken> Sorry I couldn't be there in person :-(
[13:05:17] <pjaitken> BTW The audio is rubbish
[13:05:25] <pjaitken> Sounds like a helicopter is in the room
[13:05:49] --- mattz has joined
[13:06:04] <mattz> I'll try to relay salient points, and at least say where we are
[13:06:12] * mattz has changed the subject to: ipfix WG
[13:06:29] <mattz> nevil on draft status
[13:08:18] <mattz> (I believe all slides are on-line, so I won't parrot slide info)
[13:08:29] <pjaitken> Thanks.
[13:08:59] <mattz> if you'd like clarificatoin of something, let me know, and I'll become more verbose
[13:09:15] <pjaitken> Thx.
[13:10:51] <mattz> benoit on protocol draft, reaction to discus comments from IESG
[13:11:21] <mattz> "IPFIX Protocol Specifications"
[13:12:37] <mattz> q: clarify yes v. no objection
[13:12:52] <mattz> yes: read, understand, vouch with my name good
[13:13:01] <mattz> no-obj: browsed through it, didn't find anything bad.
[13:13:07] <mattz> dan sez: that's right
[13:13:30] <mattz> Jari DISCUSS
[13:15:18] <mattz> simon: don't log errors for every sequno. out of seq packets should be handled gracefully
[13:15:56] <mattz> dplonka: wanted to add to improve what's happening today; ops might not know there are problems
[13:16:45] <mattz> b :not sure if current sentence says every occurence
[13:17:03] <mattz> dplonka: log used to inform operator, not meant to log everything.
[13:17:27] <mattz> simon: will wait to see implementation guidelines.
[13:17:46] <mattz> ?: when you say log, want a counter, or just printing error msg
[13:18:09] <mattz> ?: don't think anyone thought about informing for every occurence, but just counters used on-demand
[13:18:37] <mattz> ?: couldn't say much useful anyway, only out of sequence...
[13:18:49] <mattz> b: but then, sysadmin could do something...
[13:19:03] <mattz> ?: what about out of sequence options vs data traffic. options may be bigger problem
[13:19:26] <mattz> b: so far, nothing for UDP. for SCTP, default proto, will seq (? - I think - mjz)
[13:19:50] <mattz> Jari DISCUSS: too many options?
[13:20:07] <mattz> propose to remove one
[13:20:28] <mattz> Jari DISCUS: template widthdraw
[13:20:47] <mattz> thought it was supposed to be reliable, but didn't see it in doc, so add sentence that must go over reliable stream
[13:21:06] <mattz> and if UDP used, can't use template widthdrawl
[13:21:40] <mattz> Brian DISCUSS: title? iana comments?
[13:21:48] --- sleinen has joined
[13:21:59] <mattz> Lars DISCUSS
[13:22:50] <mattz> juergen: DTLS .. we use UDP as unidirectional data. DTLS requires bidirectional. so can't use in some cases
[13:23:18] <mattz> juergen: lars is OK with mentioning it, showing why it can't be used (or when it could be used)
[13:23:37] <mattz> q: "not SCTP"?
[13:23:42] <mattz> must is PR-SCTP
[13:23:51] <mattz> Bill Fenner DISCUSS
[13:24:14] <mattz> references fixes
[13:24:22] <mattz> "easy"
[13:24:27] <mattz> Cullen DISCUSS
[13:25:03] <mattz> believe misunderstanding, will meet with Cullen to clarify and see which are real issues
[13:25:34] <mattz> clarify: DISCUS: showstopper. must be resolved with relevant AD
[13:25:43] <mattz> COMMENT: optional, but if editing, should fix
[13:26:01] <mattz> [mjz: I may have said DISCUSS where Benoit said COMMENT, see slides]
[13:26:27] <mattz> are preparing draft about security reviews...
[13:26:37] <mattz> (above from Dan from clarify to now)
[13:26:48] <mattz> Sam Hartman DISCUSS (security)
[13:27:36] <mattz> bc: see strong connection between ipfix and syslog. sending in the same way. work with them to come up with a single solution
[13:27:47] <mattz> say "if possible", think syslog may be in direction of TLS
[13:27:58] <mattz> chris lonvic: co-chair syslog stuff.
[13:28:06] <mattz> request for secure transport there too
[13:28:27] <mattz> impl of TLS out there. SSL. request was to define threat model, and see what address
[13:28:33] <mattz> that is all in charter, look and see if it applies
[13:28:40] <mattz> did decide to use TLS with that.
[13:28:55] <mattz> a company is claiming there is some IPR with what going along with TLS draft
[13:29:11] <mattz> company making claim, has put in a set of terms for use of IPR. you can look
[13:29:32] <mattz> asking if terms are reasonable for claim. if consensus in wg is yes, continue on w/draft
[13:29:38] <mattz> otherwise will step back and look at alternatives.
[13:29:47] <mattz> ipsec, beep are possible
[13:30:09] <mattz> we will decide IPR by 19th of July
[13:30:28] <mattz> back to benoit
[13:30:45] <mattz> PR-SCTP, have possibly unreliable streams, so may need dtls.
[13:30:52] <mattz> there is a dtls-for-sctp draft
[13:31:00] <mattz> might need to wait for draft if want TLS.
[13:31:09] <mattz> dan: yes. suggest communicate with sam hartman directly
[13:31:23] <mattz> see if he is happy with solution, and he understands what text will be included in doc
[13:31:38] <mattz> bc: yes in syslog - ipfix in sync?
[13:31:48] <mattz> dan: mentioning dependencies that could cause a delay in document
[13:31:57] <mattz> not judging solution
[13:32:22] <mattz> chris: on should be algned, talked with david harrington. if enough similarities, would like to see for same rasons you mention
[13:33:01] <mattz> bc: what about section where ipsec or TLS not an option. ... will probably have to discuss with Sam directly.
[13:33:09] <mattz> new issue: key management.
[13:33:24] <mattz> talked about IKE, would need IKEv2, tho (at least told)
[13:33:56] <mattz> ESP rather than AH: will change as requested
[13:34:02] --- sebastien.pierrel has joined
[13:34:11] <mattz> TLS requests... thinking about adding a new port
[13:34:28] <mattz> juegen: port is available, so could have 4740 for TLS
[13:34:45] <mattz> need security expert to either write or review text.
[13:34:56] <mattz> if you have right background, please volunteer...
[13:35:25] <mattz> nevil: working through discus points; will need to talk with IESG directly, have started doing that
[13:35:32] <mattz> next speaker: Tanya
[13:35:38] <pjaitken> Thx.
[13:36:16] <mattz> juergen: lots of feedback on AS, so that's what tanya will talk about. no feedback on info model
[13:36:36] <mattz> current version is -09; not all comments. submitted too early :D
[13:36:49] <mattz> will be quick -10. recommend wait for -10 if you haven't read -09
[13:36:50] <pjaitken> There are no slides for this?
[13:37:08] <mattz> there are here, let me look at the page
[13:37:33] <pjaitken> Not on the Agenda page.
[13:37:47] <mattz> sigh. I'll try to be verbose
[13:37:52] <pjaitken> :-o
[13:37:53] <mattz> issue1: too many exotic examples
[13:38:10] <mattz> issue2: IPFIX limitations for usage-based billing
[13:38:24] <mattz> if you can hear Tanya, she's mentioning all points
[13:38:43] <mattz> ipfix not compliant to reliability requirements for billing in 2975
[13:38:57] <pjaitken> Actually, Tanya has a stronger voice than any of the men so far :-o
[13:38:57] <mattz> so changes to ipfix-as
[13:39:02] <mattz> - add section (4.2) on limitations
[13:39:07] <mattz> - add several warnings
[13:39:08] <pjaitken> Possibly just a better mike?
[13:39:16] <mattz> - aaa examples ont removed but warnings added
[13:39:35] <mattz> no, she's holding the mic to her mouth; benoit had it clipped on
[13:39:55] <mattz> reliability extensions: should go into draft-bclaise-ipfix-reliability-01.txt
[13:40:07] <mattz> issue3: reporting tcp flags
[13:40:15] <mattz> ipfix applicability to attack detection
[13:40:19] <mattz> tried to give some examples in as
[13:40:27] <mattz> occurence of tcp flags important
[13:40:35] <mattz> but: currently no direct support in ipfix
[13:40:43] <mattz> - no ie for counting syn pakcets
[13:40:49] <mattz> - tcp flags not defined as flow keys in ipfix-info
[13:40:58] <mattz> ipfix ie: tcpcontrolbits (per flow) defined as bitfield
[13:41:05] <mattz> bit=1 if any packet of flow contained the flag
[13:41:14] <mattz> bit=0 if no packet contained the flag
[13:41:19] <mattz> what to do?
[13:41:29] <mattz> report every connection as separate bi-flow
[13:41:45] <mattz> only partial solution; need many records
[13:41:58] <mattz> approach 2: observe flowendreason
[13:42:08] <mattz> but also only partial solution
[13:42:22] <mattz> depends on timeouts; can terminate because of lack of (ipfix??-mjz) resources
[13:42:34] <mattz> approach3: use PSAMP IEs
[13:42:40] <mattz> full solution, high effort
[13:43:00] <mattz> approach 4: introduce new IEs
[13:43:16] <pjaitken> Q: why not just request the IPFIX IE is created?
[13:43:46] <mattz> [i'll ask nevil to relay]
[13:43:48] <pjaitken> OK, she just covered that.
[13:44:33] <mattz> other issues:
[13:44:44] <mattz> * exsample IP needs to be from 3330
[13:44:52] <mattz> done, but had to change
[13:44:56] <mattz> * edits
[13:45:03] <mattz> * too IPv4 centric
[13:45:09] <mattz> will show how applies to v6
[13:45:29] <mattz> will move v6 things from limitations section to relation to other protocols
[13:45:38] <mattz> * stronger statement on use of IPPM metrics
[13:45:52] <mattz> add recommendation to should metrics where applicable (for QoS monitoring)
[13:46:13] <mattz> as-biased view on future work items
[13:46:21] <mattz> new IEs for TCP flags, flag counters
[13:46:26] <mattz> 2. bi-flow draft.
[13:46:31] <mattz> need by security folks
[13:46:40] <mattz> 3. configuation of IPFIX exports and collectors
[13:46:59] <mattz> ipfix mib, xml data model, related: nsis metering
[13:47:29] <mattz> juergen: haven't decided if ipfix mib usable for config
[13:47:40] <mattz> 4. reliability extension. because of usage based billing
[13:48:03] <mattz> 5. file format. want to use for post-incident analysis; research; maybe providers
[13:48:36] <mattz> jurgen: any comments?
[13:48:46] <mattz> we are done with this section of the agenda
[13:50:05] <mattz> [was distracted]
[13:50:35] <mattz> dan: if believe doc has some specific items that need review; and suspect may have problems in IESG; can request an "early review"
[13:51:04] <mattz> process in experiment w/in IESG, to try to resolve issues like you saw with the protocol ahead of IESG review
[13:51:40] <mattz> potential new work items section next
[13:52:00] <mattz> will ask if WG will want to add as milestone.
[13:52:10] <mattz> will have a short presentation, then hum on if doc to be wg doc
[13:53:22] <mattz> elisa boschi: ipfix implementation guidelines
[13:53:37] <pjaitken> OK, I can hear her well.
[13:53:48] <mattz> she is really holding the mic up to her mouth :)
[13:54:06] <pjaitken> P... P... P...
[13:54:13] <mattz> that's the downside
[13:55:03] <mattz> general guidelines reflect structure of proto draft to easily find things
[13:55:27] <mattz> new section on extending info model
[13:55:45] <mattz> [allison mentioned this being a problem in the past for other TSV things last night in the offpath both]
[13:56:05] <mattz> [that is, that if you don't specify ways to extend, people twist things in ways you really would rather not like]
[13:56:43] <mattz> changes from -01
[13:57:42] <mattz> open issues and action items
[13:58:06] <mattz> conclusions
[13:58:24] <mattz> comment! want it as a WG item in [by?] august
[13:58:35] <mattz> juergen: work for a while, several presentations
[13:58:41] <mattz> hum for being a wg item
[13:58:51] <mattz> me: moderate
[13:58:54] <mattz> hum for concerns
[13:58:56] <mattz> (zero)
[13:59:03] <pjaitken> I hummed for the first.
[13:59:16] <mattz> jurgen declares consensus as a WG doc; please post as a wg draft next time
[13:59:32] <mattz> next: elisa on testing doc
[13:59:38] <sleinen> Paul, do you want me to hum for you next time? :-)
[13:59:56] <mattz> motivation
[14:00:02] <pjaitken> If it's quiet and my hum is needed! :-)
[14:00:21] --- IPFIX has joined
[14:00:49] <mattz> planned for -01
[14:01:48] <mattz> questions to
[14:01:54] <mattz> jurgen: any issues?
[14:01:55] <mattz> nope
[14:01:59] <mattz> hum for wg doc
[14:02:01] <mattz> me: moderate
[14:02:03] <pjaitken> Hum!
[14:02:06] <mattz> concerns against:
[14:02:08] <mattz> silence
[14:02:15] <mattz> jurgen declares consensus for wg doc
[14:02:28] <mattz> dan r: didn't want to ask q before hum... like consensus
[14:02:42] <mattz> what will this doc be used for?
[14:02:59] <mattz> e: idea is to provide detailed description of tests used for interoperability so future implementors may use same test
[14:03:16] <mattz> dan: if I'm an implementor, reference for conformance testing?
[14:03:18] <mattz> yep
[14:03:23] <mattz> jurgen: in charter
[14:03:27] <mattz> dan said OK
[14:03:31] <pjaitken> Good.
[14:03:44] <mattz> next up, elisa on reducing redundancy in ipfix and psamp reports
[14:04:28] <mattz> benoit new co-author, improved doc
[14:04:36] <mattz> motivation
[14:06:07] <mattz> data reduction (dependencies)
[14:06:33] --- IPFIX has left
[14:06:35] --- gerhard has joined
[14:07:00] <pjaitken> Hi Gerhard!
[14:07:12] <mattz> changes from -01
[14:07:22] <gerhard> hi paul
[14:08:06] <mattz> new structure
[14:09:29] <mattz> conclusions
[14:09:38] <mattz> most mature, oldest. want a wg item by aug 06
[14:09:45] <mattz> jurgen, back to humming
[14:09:47] <mattz> who things should be
[14:09:52] <mattz> (moderate)
[14:10:01] <pjaitken> Hum, yes.
[14:10:02] <mattz> who has a problem with wg doc
[14:10:05] <mattz> (slience)
[14:10:15] <mattz> juergen says please post next version as wg doc
[14:10:25] <mattz> [so I guess he implicitly declared consensus]
[14:11:10] <mattz> next: IPv6 MIB Modules
[14:11:24] <mattz> juergen giving, authors not here will be at next meeting
[14:11:37] <mattz> past IPFIX-related MIB activities
[14:12:01] <mattz> psamp had to do work missing from ipfix since we didn't do it
[14:12:29] <mattz> Scope of MIB Modules
[14:12:42] --- irino has left
[14:12:55] <mattz> [me: missed color associations for this one]
[14:13:02] <mattz> Scope of MIB Modules, with detail
[14:13:21] <mattz> only thing missing to make IPFIX, flow statistics
[14:13:41] <mattz> probe MIB split off from PSAMP (they call exporter mib)
[14:13:48] <mattz> same time, Collector mib
[14:13:59] <mattz> so now see collection that is IPFIX mib
[14:14:03] <mattz> New Drafts
[14:14:27] <mattz> IPFIX-EXPORTER-MIB
[14:14:51] <mattz> taken from psamp, and enhanced by flow statistics
[14:17:27] <mattz> IPFIX-COLLECTOR-MIB (actually been on that one for a while)
[14:17:47] <mattz> on configurability... exporter mib is written as r/w
[14:17:52] <mattz> but that's something to discuss
[14:18:01] <mattz> there are several people that severely doubt that makes sense
[14:18:16] <mattz> benoit: because charter doesn't say anything about config. w/mib
[14:18:26] <mattz> yes, that's a reason why we could remove r/w
[14:18:39] <mattz> tanja: think config is needed, though. so would recommend working on this
[14:18:45] <mattz> juergen: q is if SNMP is right protocol
[14:18:52] <mattz> benoit: two levels of config
[14:18:59] <mattz> from collector mib, configure only the exporter
[14:19:06] <mattz> but also r/w exporter mib, in mib itself
[14:19:14] <mattz> first q: need SNMP SET
[14:19:22] <mattz> second q: need both of them, seems to be redundant
[14:19:25] <mattz> juergen ?
[14:19:39] <mattz> benoit: do we want SNMP SET in both collector and exporter
[14:19:42] <mattz> think thats redundant
[14:19:52] <mattz> juergen: yes, but, expect will be implemented in different boxes
[14:20:00] <mattz> different app scenarios, need to decide individually
[14:20:12] <mattz> benoit: but could address any box with SNMP
[14:20:17] <mattz> Open Issues
[14:20:39] <mattz> Juergen's Document Status
[14:20:49] <mattz> believe doc is early; need a bunch of imporvements
[14:20:51] <mattz> some stats missing
[14:20:56] <mattz> see lots of need for improvement in doc
[14:22:00] <mattz> now nevil as chair
[14:22:04] <mattz> any q at this stage?
[14:22:08] <mattz> group is passive :)
[14:22:19] <mattz> discussed MIB in dallas, and strong consensus to do it there
[14:22:24] <mattz> delighted that so much work has been done
[14:22:34] <mattz> plenty of things to still think about
[14:22:44] <mattz> including benoit's point
[14:22:59] <mattz> knew that, when wrote charter. this activity has a 12 mo time scale, vs 6 mo for other.
[14:23:02] <mattz> looks as though on-track.
[14:23:10] <mattz> formal point, hum please if happy to see work as wg
[14:23:15] <mattz> (moderate)
[14:23:21] <mattz> hum if problems
[14:23:25] <mattz> (silence)
[14:23:33] <mattz> nevil declares consensus, and will pick up as wg item
[14:23:38] <pjaitken> Is it about the same level of hum each time?
[14:23:50] <mattz> I would say yes.
[14:24:09] <mattz> maybe slightly less for the compliance doc... but it's kind of hard to tell
[14:24:14] <mattz> (my opinion only)
[14:24:26] <mattz> next up: bidirectional flow export using IPFIX
[14:24:31] <mattz> brian trammell
[14:24:59] <mattz> Motivation
[14:25:29] <mattz> Possible Biflow Export Methods
[14:25:34] <mattz> Record Adjacency
[14:25:42] <nevil> I agree with mattz. also, no-one has hummed against. we'll see how it goes on the mailing list
[14:26:23] <mattz> Common Properties
[14:26:45] --- irino has joined
[14:27:07] <mattz> Multiple Information Elements
[14:27:14] <mattz> (proposal, not in draft, discussed on ML)
[14:29:42] <mattz> Single Record Biflows
[14:30:00] <mattz> Single Record Biflows (second, slide8)
[14:30:16] <mattz> Policies for Reverse IE Definition
[14:31:12] <mattz> Direct Allocation of Reverse IEs
[14:32:02] <mattz> slide 11
[14:32:36] <mattz> Reverse PEN
[14:33:00] <mattz> so we propose to do something different...
[14:33:27] <mattz> slide 13
[14:34:19] <mattz> plonka: if private enterprise wants own counter type, would they need another private enterprise #?
[14:34:33] <pjaitken> saves me asking the same question then...
[14:34:35] <mattz> right now, the way I do this, info elts w/in iana managed space, use this reverse pen
[14:34:48] <mattz> ones that I allocate myself, allocate one forward, and one reverse
[14:35:19] <mattz> steve casner: problem that ones that aren't reversable are implicitly defined by this?
[14:35:24] <mattz> yes, but treated as illegal info elts
[14:35:36] <mattz> (by the collecting process)
[14:35:38] <mattz> not clear in draft
[14:35:58] <mattz> alo mentioned dave's point not clear earlier, will also clarify in draft
[14:36:05] <mattz> Since Dallas
[14:37:08] <mattz> Next Steps
[14:37:46] <mattz> ?: explain how build key for bidirectional flows
[14:38:00] <mattz> addressed in doc, not addressed well in slides
[14:38:05] <mattz> slide 7
[14:38:16] <mattz> have directional and non-dir key field
[14:38:38] <mattz> define source of biflow == source of packet sent by flow initiator
[14:38:47] <mattz> so equal to "forward direction"
[14:39:07] <mattz> ? in this case, why do you need reverse elts for all info elts?
[14:39:20] <mattz> most common application will be reverse for counters
[14:39:24] <mattz> but other cases...
[14:39:32] <mattz> want tcp flags fwd/reverse
[14:40:00] <mattz> want measurement arch that use 802.1q, where vlan==obs point. want fwd/rev vlan id.
[14:40:09] <mattz> (use 802.1q for trunking back)
[14:40:16] <mattz> is "slight-abuse" but seen it
[14:40:24] <mattz> juergen: id'd lots of things when doing info model
[14:40:42] <mattz> ? DSCP is attr of flow, expect same in both direction
[14:40:45] <mattz> but sometimes things are not as expected
[14:41:07] <mattz> have seen defns of flow key st different dscp different flow
[14:41:28] <mattz> ? reducing export from device, good. but in turn, expect device to do correlatoin
[14:41:39] <mattz> yeah, only do it where makes sense. not if on line card
[14:41:56] <mattz> but pc's with DAG cards, best way to reduce biflow data, is to do it asap, if can reduce want to do so
[14:42:18] <mattz> emile: understand scope, it's limited. single meter
[14:42:32] <mattz> emile: maybe enough to add one ie to say if ingress or egress in template
[14:42:39] <mattz> but then back to exporting flow key data twice
[14:43:17] <mattz> emile: to be less specific, describve how might work if several meter in one device
[14:44:00] <mattz> juergen: checked this already when writing. it applies. doesn't match well to arch. if in line card. but matches well to highspeed probe.
[14:44:05] <mattz> not ideal thing for high-speed router
[14:44:09] <mattz> but ipfix is not limited to routers
[14:44:20] <mattz> request for biflow is strong. since first day of wg
[14:44:31] <mattz> agreed to uniflows in beginning, but here is an idea to satisfy biflow requirement
[14:44:45] <mattz> emile: agree what looking for. but technique that works only with one meter process is not enough
[14:44:52] <mattz> emile: IP is not bidirectional
[14:45:03] <mattz> IP is not bidir, but most of L7 protos on top are.
[14:45:09] <mattz> if trying ot understand what's happening on net, with apps
[14:45:30] <mattz> juergen: discussion is whether want to do biflow or not. shouldn't discuss this. want to focus on HOW
[14:45:54] <mattz> emile: but do we want it to work using different boxes
[14:46:32] <mattz> juergen: charter says we should look for it. it's clear if asym routing, can't do it
[14:46:40] <mattz> there is limitation, but could be used at customer edge
[14:46:56] <mattz> trying to do it efficiently
[14:47:07] <mattz> missed emile's final comment...
[14:47:22] <mattz> benoit: ingress v. egress. think you have to flag interface of router as internal/external
[14:47:29] <mattz> if rely on first packet, don't know if get right one
[14:47:38] <mattz> if long lasting flows, could be a problem
[14:48:05] <mattz> wrt long-lived flows, have that problem operationally. our solution is ... forward and reverse "initial" and "rest"
[14:48:08] <mattz> tcp flags
[14:48:18] <mattz> why say "best effort" in document. sampling causes issues
[14:48:40] <mattz> if collecting process can stitch together w/add'l info, more info.
[14:48:51] <mattz> juergen: continue discussion off line.
[14:48:59] <mattz> hum. but not whether or not biflow
[14:49:07] <mattz> hum on if this doc is right direction to support biflows with ipfix
[14:49:17] <mattz> (moderate)
[14:49:26] <mattz> ?: most controvsersial point is who originates flow, where problem start
[14:49:40] <mattz> if don't do that, whatever packet we capture, create flow... then treat as flow originator
[14:49:54] <mattz> rather than using tcp flags, easier to just use first packet, and ...
[14:50:18] <mattz> also issue with sampling. small subset of packets. in general how valuable it is... maybe not provide at all, not accurate in general
[14:50:30] <mattz> (who started flow)
[14:50:39] <mattz> most devices do sampling
[14:50:51] <mattz> we should just ignore who started, can't provide info
[14:50:58] <mattz> why "metering process best effort"
[14:51:07] <mattz> have to chose direction, to assign direction of flow keys
[14:51:20] <mattz> when export a biflow, to the metering process best estimation
[14:51:31] <mattz> need add'l info. like selector informaiton.
[14:51:40] <mattz> juergen: think not far from agreement,
[14:51:43] <mattz> continue offline
[14:51:47] <mattz> hum if problem
[14:51:49] <mattz> (silence)
[14:51:56] <mattz> so agreeement on all 5 docs to become wg doc
[14:52:09] <mattz> two smal presentations at the end.
[14:52:18] <mattz> IPFIX-based file format
[14:52:20] <pjaitken> We're almost out of time.
[14:52:28] <mattz> yep
[14:52:29] <pjaitken> That last item took a very long time.
[14:53:00] <mattz> this is largely a different doc from the -00 doc from paris a while ago
[14:53:07] <mattz> The Idea
[14:54:46] <mattz> The Document
[14:56:22] <mattz> The Future
[14:57:27] <mattz> dan: like the approach. like gaining impl experience. at this point in time, move 5 docs...
[14:57:38] <mattz> did not ask audience, but hope people will read/comment on those 5
[14:57:53] <mattz> by next nov/mar with impl reports and and showing that it is useful
[14:58:02] <mattz> and interoperate, then very a good case for pushing on stds track
[14:58:12] <mattz> juergen: if have to make design decisions, bring to list, and use it.
[14:58:42] <pjaitken> No time for Gerhard?
[14:58:43] <mattz> no time left... one presentation we will not do. but,
[14:59:06] <mattz> please read doc, see agenda for slides and presentation in materials
[14:59:14] <mattz> will probably be presentation next time
[14:59:29] <gerhard> pity
[14:59:49] <mattz> when 5 docs are sent in, read, initially is the time to change direction
[15:00:02] <mattz> nevil: milestones in charter. given presentations, not suggesting change milestones
[15:00:35] <mattz> authors here think they can do wg version by aug
[15:00:51] <pjaitken> Thanks for scribing Matt!
[15:00:59] <gerhard> jup, thanks
[15:01:21] --- sebastien.pierrel has left
[15:01:31] --- sleinen has left
[15:01:32] <miaofy> Very informative, thanks Matt!
[15:01:35] --- irino has left
[15:01:37] --- miaofy has left
[15:02:02] <mattz> you're welcome
[15:04:47] --- mattz has left
[15:05:57] --- nevil has left
[15:06:47] --- pjaitken has left
[15:06:55] --- gerhard has left
[15:23:58] --- sleinen has joined
[15:24:05] --- sleinen has left