[02:44:53] mawatari joins the room [03:55:55] akoba joins the room [03:55:57] Brian Trammell joins the room [03:58:01] inacio joins the room [03:58:14] nevil.brownlee joins the room [04:00:00] haruhikonishida joins the room [04:01:14] Just in time - had to creat a new jabber account for a new machine first :-) [04:01:45] some technical difficulties with the projector, we're getting help. [04:01:51] 'afternoon, Nevil, all! [04:02:00] mawatari leaves the room [04:02:01] do we have a jabber scribe? [04:02:14] hi Brian [04:04:31] audio levels are very, very low. [04:04:33] nnnshin joins the room [04:04:59] low, but audible [04:05:33] no one's really on the mic's yet. [04:05:43] okay good [04:06:30] I heard what sounded like Juergen way in the background and thought I was missing something... [04:08:01] the projector is working. [04:08:17] audio good? [04:08:38] fine now, tnx [04:08:42] audio excellent [04:09:58] arifumi joins the room [04:12:57] yep, I'm here. [04:14:54] (on anon, I can summarize the changes and the next steps via Jabber, if necessary. beyond those the slides are mainly there for people new to the group or the draft.) [04:16:04] What's Benoit wearing ?? [04:16:09] (Could someone take a picture of Benoit, please?) [04:16:18] picture taken [04:16:30] then, plz upload :) [04:16:32] its a samuri(sp?) hat [04:17:51] juergen took the picture [04:19:04] dromasca joins the room [04:25:01] if there's no use case for configuring SCTP ordered/unordered delivery, why is it in the protocol itself? [04:26:32] although i agree in general that simplifying the config model is a good idea [04:26:32] so [04:27:04] so? [04:27:24] is there an agreement there is no use case for that? [04:27:36] not a big enough one... [04:27:44] so I suppose I agree with taking it out [04:27:46] will do [04:27:46] tx [04:47:46] I'm pretty strongly in favor of Solution 1 here. Semantics of IPFIX records as collections of Information Elements are not an issue that is specific to structured data, but are an issue for the entire protocol. [04:48:14] (this is something we address lightly in anon -> "this IE is not real but you can pretend it is") [04:48:20] solution 2 looks messy to me [04:48:39] (it's something that will need to be quite directly handled in a future aggregation draft) [04:49:54] so if we want to tackle semantics, then we need to do it at an IE/Record level protocol-wide, or specific to each situation. [04:50:09] and I second nevil [04:50:15] solution 2 looks messy [04:50:25] it reminds me of the whole pre/post hack. [04:50:39] Solution 3 is waaaaaaaaaaaaay out of scope [04:50:40] exactly [04:51:18] thanks Chris :) [04:51:36] there are two questions [04:51:41] is there a use case for OR [04:51:42] AND [04:51:49] is structured data the best place to solve it [04:52:14] second question [04:52:21] do we solve it in structured data? [04:52:32] lhotka joins the room [04:53:00] lhotka leaves the room [04:53:02] I'll send a comment to the list in a few days [04:58:27] Maybe we need an 'application id' IE ??? [04:58:44] if we had that, we'd just need a set of values for it [05:01:29] I strongly suspect there already exists at least one, probably more than one, implementation of such a thing. [05:01:37] vdharani joins the room [05:01:41] then as always the question is whose values to we use. :) [05:06:15] isnt the voice too low? [05:06:26] a little, yes [05:08:18] is it better? [05:08:31] yes, definitely. thanks. [05:15:26] two important points here: [05:15:50] they are? [05:16:08] 1. in publishing -00, we added a Security Considerations section [05:16:13] on what brian? [05:16:26] (oops!) [05:16:31] (re: subtitle) [05:17:19] 2. we've received some commentary on additional anonymization techniqes [05:17:28] and will be adding these for -01 [05:17:54] (these are on the last slide) [05:18:18] (Juergen is correct) [05:18:58] if anyone is actively applying anonymisation, please read and let us know if there's something you're using that you can't represent here... [05:19:36] (thanks, Dan!) [05:21:36] akoba leaves the room [05:30:11] and now we have an IANA registry that has enough information in it.. [05:30:36] btw, we already have IE 256, ethernetType [05:31:06] I agree with Juergen on this - it should be discussed at least within IPFIX WG [05:31:08] (unless I'm missing part of this discussion) [05:31:45] BTW, the experts for this are the mIPFIX WG chairs [05:32:05] what we really need, I think, is a better process, something between a WG document and just a set of IEs going to IANA, "IE-DOCTORS" by analogy with MIB doctors... [05:32:27] that's what 'expert review' is intended to provide [05:32:37] true... [05:33:01] question for the presenter, how many IEs does he want to add? [05:33:16] 3 was in the presentation [05:33:56] ah [05:34:02] okay, I see that. was not entirely clear. [05:35:17] also: will a simple IETF last call get it in front of enough people? [05:35:49] individual submission publication is handled by the Independent SUbmissions Editor, [05:35:52] (there may be advantages to having the IPFIX working group, or a chair thereof, to the other WGs) [05:36:00] (i.e., exactly what Dan said.) [05:36:09] it doesn't go through the usual IETF process [05:36:53] just the three new IEs, yes? [05:36:55] okay, thanks [05:37:13] akoba joins the room [05:38:19] thanks, was confused... the difference between this and ethernetType is clear now. :)\ [05:38:34] one could use the libpcap frame type numbers [05:38:49] are those stable across implementations? [05:39:11] I think so, at least the ones on the code from tcpdump.org [05:39:12] oh, wait, yes, they have to be... [05:39:27] Nevil, good idea. [05:39:38] something to suggest to the authors via email or the list, definitely [05:40:16] (Ah, Kobayashi-san is here. Hi!) [05:40:40] Brian, thank you. [05:54:22] The framework is supposed to set out how to build a mediator box, the original idea was to then go on to publish specific rfcs for particular intermediate provcesses [05:54:42] right... [05:54:54] Juergen's proposal to explore what really *has* to be in the framework is the logical next step [05:55:24] I see the mediator protocol draft as more analogous to the implementation guidelines than anything else [05:55:24] so Benoit's draft is a good step towards identifying those [05:55:38] but it implies that we delay the framework [05:55:45] which is probably not a bad idea [05:55:50] (did you just lose audio?) [05:55:53] yes, that's the [rpblem [05:55:56] yes [05:56:02] and yes, I've lost audio [05:56:12] okay [05:56:19] that's all of us then [05:56:26] and it doesn't seem to want to restart for me, sigh [05:56:27] yeah [05:56:34] here either [05:56:37] -> server problem [05:56:51] maybe that's telling us that it's 1700 in Hiroshima ? [05:57:09] we're now aware [05:57:12] hm [05:57:13] of the audio loss [05:57:21] yeah, could be a restart while it archives...? [05:57:39] 1700 meaning 5PM? [05:57:40] we have no idea, but there is only a few minutes less. [05:57:50] Benoit and atsushi talked on IEs to be add. (last dot on open issues draft) [05:57:50] it is aout 3pm, right? [05:58:08] we are wrapping up here, sorry for this [05:58:28] but i read you comments at the microphone [05:58:30] ok, tnx Dan [05:59:02] akoba leaves the room [05:59:05] and we can take the followup on this draft to the list... [05:59:18] right [05:59:26] nnnshin leaves the room [05:59:32] dromasca leaves the room [05:59:38] haruhikonishida leaves the room [06:00:00] vdharani leaves the room [06:01:21] ok, 'bye for now :-) [06:01:37] bye! [06:01:42] Brian Trammell leaves the room [06:02:02] arifumi leaves the room [06:03:52] nevil.brownlee leaves the room: offline [06:06:05] inacio leaves the room [19:59:48] ipfix joins the room [20:01:21] ipfix leaves the room [20:01:50] Tobi joins the room [20:02:43] Tobi leaves the room