Thursday, August 1, 2013< ^ >
bebemaster has set the subject to: End
Room Configuration
Room Occupants

[07:12:44] John Dowdell joins the room
[07:16:19] John Dowdell leaves the room
[07:21:32] John Dowdell joins the room
[07:23:45] John Dowdell leaves the room
[09:04:49] joins the room
[09:05:01] Ulrich Herberg joins the room
[09:05:05] Ulrich Herberg leaves the room
[09:12:15] leaves the room: Logged Out
[09:50:35] l-duehrsen joins the room
[10:26:58] thomas.heide.clausen joins the room
[12:09:42] l-duehrsen leaves the room
[12:31:31] Jiazi YI joins the room
[12:31:58] Jiazi YI leaves the room
[12:45:08] l-duehrsen joins the room
[12:48:30] l-duehrsen leaves the room
[13:00:21] Jiazi YI joins the room
[13:08:05] l-duehrsen joins the room
[13:08:09] Lotte joins the room
[13:09:33] Ulrich Herberg joins the room
[13:11:35] John Dowdell joins the room
[13:12:33] Ulrich Herberg leaves the room
[13:14:58] Eimann joins the room
[13:15:16] Eimann is now known as Dominik Bay
[13:18:03] jpmacker joins the room
[13:21:48] adrianfarrel joins the room
[13:22:44] teco.boot joins the room
[13:24:01] <thomas.heide.clausen> Are there slides for mgmt applicability, I didn't see them on the agenda page
[13:26:29] bebemaster joins the room
[13:27:01] <thomas.heide.clausen> Question: what's the hold-up for report-mib? It seems that it was almost-there for the last 2-3 IETFs?
[13:27:15] yuichi.igarashi joins the room
[13:27:29] <Lotte> do you want us to ask at the microphone?
[13:27:37] <thomas.heide.clausen> yes
[13:30:04] <thomas.heide.clausen> Q: Research Group - does this mean that DLEP is moving to the IRTF?
[13:30:56] <Lotte> did that question answer your question?
[13:31:23] <thomas.heide.clausen> Now it did, thanks
[13:32:08] <bebemaster> Are there any general notes (or summary) about the 2 hour meeting that could be released to the list?
[13:32:22] <thomas.heide.clausen> Seconding Justin's question.
[13:32:26] <jpmacker> Design Team is a more apropos name for this DLEP side effort.
[13:33:17] <thomas.heide.clausen> IT's good that "everybody else want to do" something, but they must have had arguments. What were those? It's a major diversion from  the current I-D
[13:33:56] joins the room
[13:34:07] <thomas.heide.clausen> Additional question:
[13:34:19] <Lotte> did the arguments stan just listed satisfy your question or should we ask explicitly?
[13:34:50] wetter joins the room
[13:34:57] <thomas.heide.clausen> what other issues were discussed during the 2-hour or 3-hour side meeting? TCP can't take that much time. IT would be very helpful if that "Research Group" would keep the WG in the loop and informed.
[13:36:16] <thomas.heide.clausen> Hang on, is DLEP a WG document or an internal Cisco-document? IF the former, then the WG really needs to be more in the loop, both on issues and on arguments.
[13:37:27] <l-duehrsen> thomas.heide.clausen:
[13:37:30] <Lotte> i'm a tad confused whcih part is supposed to a question and what are comments
[13:37:38] <thomas.heide.clausen> The two last were questions
[13:37:43] <thomas.heide.clausen> [and I have read -04]
[13:39:50] <bebemaster> Please make this comment to the mic:  Could a written summary/overview of the discussion be posted to the list?
[13:39:51] <thomas.heide.clausen> So that crystalizes into a request: could the "research group" post their currently perceived set of metrics on the list?
[13:40:35] <adrianfarrel> Just for the minutes...
Forming a WG Design Team is OK and normal. The chairs will post a brief charter for the DT including what it is intended to achieve; what its timelines are; what its deliverables are; and who is on it.
Then I will grant the request for an IETF list for this DT.
The DT will be expected to report back.
[13:41:10] <l-duehrsen> does this answer your questions?
[13:41:44] <thomas.heide.clausen> Mr. AD: will there be public archives of that "research group" list discussion, or is this going to be (like some other WG design team you know of) a black box with magically no records?
[13:43:59] <adrianfarrel> That is up for discussion depending on the charter I see and the commitment to reporting
[13:44:22] <thomas.heide.clausen> In that case, do record an objection from me, mr. Farrel
[13:44:39] <adrianfarrel> Recorded
[13:45:06] <adrianfarrel> If you want to detail your objection and the background, I would be happy to consider it
[13:45:15] <thomas.heide.clausen> While you are at it, as the WG chair indicated that the design team was composed from the "maximal interested people", then I infer that the WG was polledfor who those were.
[13:46:17] <thomas.heide.clausen> Mr. Farrel: certainly. In another WG, there was a design team, on which I (and others) were on and on which we expressed objections to design choices. Those objections were not heard, and when approaching the responsible AD, the reply was "as there's no public record of those objections having been raised, I can't act on it - suck it up!"
[13:47:08] <thomas.heide.clausen> Mr. Farrel: I believe it useless to, in public, state which WG and design team I am talking about. If you can't infer, ask in private.
[13:48:53] <bebemaster> I would like to second Thomas' desire for greater transparency in document development.  It need not stifle progress but greater information flow will be beneficial for all.
[13:50:31] <adrianfarrel> I am not talking about history. You can do that via email.
[13:50:39] <adrianfarrel> Let's handle the case at hand
[13:50:48] <adrianfarrel> RFC 2418 section 6.5 sets the scope
[13:51:25] <thomas.heide.clausen> Mr. Farrel: you cannot ask for justification for my request, and then state that previous IETF experience can't be used as justification.
[13:51:55] <adrianfarrel> Since we are not clearly aware of the purspose of this new team, it is hard to say whether it would be particularly harmful for it to operate behind closed doors
[13:52:27] <adrianfarrel> Thomas, I can and do make that assertion.
[13:52:41] <thomas.heide.clausen> Mr. Farrel: You asked for my opinion, and I expressed it.
[13:52:48] <adrianfarrel> Thank you for doing so
[13:55:37] <jpmacker> I agree with that we need to see a design team request and purpose as well as a schedule. On a logistical note we should definitely force the dropping of RG as the requested name it is a DT if acceptable.
[13:55:42] <thomas.heide.clausen> For when mr. Perkins is done, a comment to issue #11: I am not sure what "subnet" means in the context of a routing protocol for MANETs, RFC5889 taken in consideration.
[13:56:16] <thomas.heide.clausen> Therefore, I do not understand how the "invalidate a subnet", "use a subnet route" or "invalidate a longer prefix from a subnet" means.
[13:57:36] <Lotte> do you want to ask for clarification at the microphone or would it maybe be easier to clarify this on the Mailing List?
[13:58:06] <bebemaster> The number of design and issues being discussed at this point gives me apprehension regarding the maturity.  Are there any implementations or planed implementations? Having interoperable implementations would relieve much of my apprehension.
[13:58:25] <Lotte> as far as I know, there are no implementations
[13:58:55] <Jiazi YI> what about planed implementations?
[13:59:27] <thomas.heide.clausen> General Q: there are a lot of design choices made, such as "multicast vs unicast RREPs" etc. Some of those are directly contradictory to my own experience for what is sound in these kinds of networks, others I really do not know. What operational/experimental experience can be provided to guide the working group? Are there interoperable implementations, or even prototypes?
[13:59:53] <thomas.heide.clausen> I think that this is more important than the "commas".
[14:00:15] <thomas.heide.clausen> For the record, reading the I-D, I wouldn't know how to make an implementation that I'd stake a claim of comformance for.
[14:00:54] <Lotte> I'm kind of expecting the implementation question to be raised in the room. if it isn't, i will ask about planned or existing implementations. ok?
[14:01:13] <thomas.heide.clausen> I would like to have my long message above read out, please?
[14:01:19] <adrianfarrel> They are looking at #13
[14:01:33] <Lotte> alrighty
[14:01:36] <adrianfarrel> Thomas, there is a long line
[14:02:03] <thomas.heide.clausen> Mr. Farrel: I was replying to the Jaber relays question. I trust the Jabber relays to be appropriately respect mike-queue.
[14:03:50] <adrianfarrel> yuppy, just giving you b/g info
[14:04:00] <Lotte> there you go ;)
[14:04:11] <thomas.heide.clausen> Comment to Chris: other reactive routing protocol designs took that approach on metrics.
[14:04:19] <Lotte> can you maybe after that answer tell me if it was satisfying or what additional info you need?
[14:04:29] <Lotte> because of the time left etc
[14:04:52] <thomas.heide.clausen> Lotte: I would still request the large question on experimentation work be posted, please.
[14:05:04] <Lotte> aye aye
[14:05:04] <bebemaster> My opinion is no.
[14:05:35] <thomas.heide.clausen> To Stan: I believe that /interoperable/ implementations are, or should be, a requirement for std. track protocols. In general.
[14:07:21] <wetter> ack
[14:07:24] <jpmacker> My WG member opinion is we need more implementation experience especially with particular new issues such as new options and interoperability with NHDP.
[14:07:41] <thomas.heide.clausen> Comment to mr. PErkins: there are a great deal of things in RFC3561 - which was experimental - that experiments have shown to not be beneficial (and, occasionally, harmful).
[14:07:48] <thomas.heide.clausen> Would Jabber scribe relay that, please?
[14:08:45] <thomas.heide.clausen> Note that "implementation of the protocol" is one thing, design-choices, even in an implementation, may be occasionally bad.
[14:09:19] <thomas.heide.clausen> Therefore, folding into any new protocol "just because it is in 3561" isn't a reasonable argument.
[14:10:23] <thomas.heide.clausen> I believe that we should not have "options" in a std. track protocol spec.
[14:10:38] <thomas.heide.clausen> At least, not such "non-interoperable" issues (say, mcast/ucast)
[14:11:34] <adrianfarrel> I tend to agree with you on options. Not a hard rule, but a guiding principle
[14:11:54] <thomas.heide.clausen> Mr. Farrel: I appreciate that.
[14:12:40] <Jiazi YI> I think the bottom line is clear: those options should be interoperable. That's the hard rule.
[14:13:11] <thomas.heide.clausen> as in "if I use option X, and you don't, we should still interoperate gracefully"? Agreed 100%
[14:14:13] <thomas.heide.clausen> But, I also consider it a failure to be able to either claim conformance whilst implementing only a subset -- or, to have to implement useless (even, interoperable) in order to claim conformance. (Think: RFPs and such, in which RFCs often are used)
[14:18:16] <jpmacker> I agree this is not ETT as the authors intended also second a renaming request to avoid confusion. And this should be Informational as a particular approach.
[14:18:28] <thomas.heide.clausen> Comment: to me, what the current speaker is saying, is indicative that Experimental is the right track.....
[14:18:59] thomas.heide.clausen raises hand
[14:19:27] <Lotte> -> microphone?
[14:19:34] <thomas.heide.clausen> Nah.
[14:19:34] <jpmacker> I would suggest Informational if it gets supported by deployment experience but that is debatable.
[14:19:45] <jpmacker> Also not need for mic.
[14:19:53] <thomas.heide.clausen> If it gets depolyment experience, then I agree with Joe.
[14:20:10] <thomas.heide.clausen> Q: for mike, are there slides for the mgmt ?
[14:20:15] <thomas.heide.clausen> Ah, nevermind ;)
[14:20:19] <adrianfarrel> no slides
[14:21:01] <thomas.heide.clausen> General comment (not really question), but I wonder if the ETT document could be made such as to apply not to a specific protocol, but to all protocols using RFC5444.....
[14:21:18] <Lotte> microphone.
[14:21:25] <thomas.heide.clausen> ...generic components /was/ a core design choice that the WG set out with back in 2005(ish) or so.
[14:21:50] <thomas.heide.clausen> Microphone when "open mic"  - it'd be out of place just now.
[14:21:55] <Lotte> alright
[14:22:13] <thomas.heide.clausen> Thank you, Lotte, for being an exceptionally reactive Jabber relay - btw.
[14:23:03] <Lotte> sorry for the confusion. I'm trying to work out which comments you want at the micriphone and which are jabber comments
[14:23:14] <thomas.heide.clausen> No confusion, you're doing great!
[14:23:27] <thomas.heide.clausen> It's a very hard task, I know ;)
[14:23:29] <Lotte> ( if you want to, it would be grat if you could just tag your mic comments/questions with an [M])
[14:23:38] <thomas.heide.clausen> Will do!
[14:23:40] <adrianfarrel> Yes, that is a trick I have seen in jabber rooms before
[14:23:45] <Lotte> thanks a lot :)
[14:23:46] <adrianfarrel> e.g. #MIC
[14:23:53] <Lotte> or so
[14:24:02] <thomas.heide.clausen> So now we're having twitter-interaction with WGs?
[14:24:34] <thomas.heide.clausen> Chris: heh ;)
[14:24:37] <adrianfarrel> There are a couple of IETF WGs that have twitter a/cs
[14:25:22] <thomas.heide.clausen> (Did not get that mumbling far from the mike...)
[14:25:48] <thomas.heide.clausen> M: If someone said that mgmt is useless, then know that that's not reflecting my position.
[14:27:56] <Lotte> (surprising that there's no RFC for jabberscribe commands…)
[14:28:40] <thomas.heide.clausen> Lotte: because you haven't written one :D
[14:28:51] <adrianfarrel> Exactly. I love volunteers!
[14:29:12] <thomas.heide.clausen> Looks like Adrian just volunteered to co-author with Lotte :D :D
[14:29:18] <adrianfarrel> If Lotte wants an RFC quickly, this could be the way. Looking for a co-author?
[14:29:26] <adrianfarrel> <snap>
[14:29:50] <Lotte> oops.
[14:31:07] <thomas.heide.clausen> Mr. Farrel: just got a batch of datatracker emails from you. Appreciated.
[14:31:34] <bebemaster> M: Has this been studied in real systems.  While more efficient depending on link dynamics it may make the network less robust.  Have you looked at this?
[14:31:36] <jpmacker> Q: for Chris will your MPR changes allow for a shared CDS set to be used from another known election process say e.g., E-CDS.
[14:32:18] <Lotte> jpmacer: mic as well?
[14:32:27] <thomas.heide.clausen> Joe: I will let Chris answer, but essentially, you can select MPRs as you already do.
[14:32:47] <thomas.heide.clausen> Joe: this I-D only allows you to select "fewer" MPRs in some cases, but you can always select "more"
[14:33:00] <Dominik Bay> Finally, a new working group for the General Area. Let's abbreviate it with chim: "Chat & Instant Messaging - Interaction & Maintenance of interactive messaging services"
[14:33:14] <thomas.heide.clausen> Joe: Thus, if you can do it in OLSRv2 as-is, you can do it with this update.
[14:33:52] <adrianfarrel> @Dominik  Can we get "CHIME-IN"?
[14:34:06] <Dominik Bay> haha
[14:34:10] <bebemaster> M: The question was relating to the first draft not the one he is currently presenting....
[14:34:12] <Dominik Bay> that'll do too
[14:34:20] <thomas.heide.clausen> Justin: same answer, actually.
[14:34:21] <Lotte> Shit, sorry.
[14:34:55] <thomas.heide.clausen> Justin: It has been implemented (at least, twice that I know of) and actually it "just" permits removing links from the topology graph that were not used for routing by OLSRv2.
[14:34:59] <jpmacker> Oops forgot the M I am old school and used Q.
[14:35:14] <Lotte> seems like taht rfc is actually necessary :)
[14:35:18] <thomas.heide.clausen> Justin: again, if your implementation feels like it needs to select these as Routing MPRs, you still can (and should)
[14:35:22] <jpmacker> Bebemaster = Justin Dean for the scribe record
[14:35:32] <thomas.heide.clausen> Lotte: looking forward to see your first draft of it ;)
[14:35:37] <bebemaster> I am not so sure as fewer links will be advertised and you are taking advantage of 2 hop information being consistent to select your valid MPRS
[14:36:14] <Lotte> bebemaster/justin: did thomas.heide.clausen s answer answer your question or is it still mic-relevant?
[14:36:30] <bebemaster> Shhh it's a secret, and it's funny when they say bebemaster at the mic.
[14:36:44] <bebemaster> in part but I am not fully satified I'm sure we will talk more
[14:37:33] <thomas.heide.clausen> Justin: essentially, you will (in OLSRv2) select routing MPRs according to "shortest paths, according to metric". In OLSRv2, you will - occasionally - also select routing MPRs on a "slightly longer than shortest path according to metric". The routing system won't use that, it'll just clutter up your topology graph over which to run your shortest path algo over.
[14:37:39] <Lotte> ssoooo bebemaster's and jpmackers questions to the mic
[14:38:03] <thomas.heide.clausen> Justin: but, again, that I-D just allows you to "not select" that - you still /can/ select it in your implementation and deployment
[14:38:31] <thomas.heide.clausen> Justin: pathological case, you can select /all/ symmetric neighbors as Routing-MPR, if you like running Dijkstra over big datastructures :D
[14:39:29] <wetter> i wonder how manets will work together with multipath-tcp
[14:39:38] <jpmacker> Good enough we can take it offline
[14:40:03] <Lotte> ok, perfect
[14:40:10] <thomas.heide.clausen> Wetter: haven't tried that myself. I know that there are some who have, but I have no information as to how and why and what comes of it
[14:44:17] <adrianfarrel> one hand
[14:44:29] <adrianfarrel> oh, 2, sorry
[14:44:36] <thomas.heide.clausen> :D
[14:44:45] <thomas.heide.clausen> Mr. farrel, do authors count? :)
[14:44:51] <Jiazi YI> [M]: I would like to announce the recent activities related to LOADng:
On the loadng draft: the new revision -09 has been released. Compared to -08, two issues: one related to non-optimal routes (reported by Marius on the MANET mailing list), and one related to RERR message propagation (reported by G3-PLC Alliance) have been addressed.
Two companion documents are also submitted:
1. Jitter consideration for reactive protocol in mobile ad hoc networks, to improve the efficiency of router discovery in reactive protocols.
2. Smart Route Request for LOADng: make use of existed routing information to reduce routing overhead in LOADng.
[14:45:04] <thomas.heide.clausen> Lotte: my question for ETT, please?
[14:45:24] <thomas.heide.clausen> M: General comment (not really question), but I wonder if the ETT document could be made such as to apply not to a specific protocol, but to all protocols using RFC5444........generic components /was/ a core design choice that the WG set out with back in 2005(ish) or so.
[14:46:15] <Lotte> doinf my best to find it
[14:46:25] <thomas.heide.clausen> Just repeated it ;)
[14:47:22] benoit.claise joins the room
[14:47:26] <thomas.heide.clausen> M: I believe that the WG should try to get the current work-items squared off (one way or another) before looking to expand the scope.
[14:47:57] <jpmacker> M: As a WG member we should be open to consider issues from VANET and sensor networks..
[14:48:18] <Lotte> thomas.heide.clausen: „M: General comment (not really question), but I wonder…“ that one?
[14:48:34] <thomas.heide.clausen> M: There's still one major charter item which seems to be only in the very initial phase.....
[14:48:41] <thomas.heide.clausen> Lotte: that was that.
[14:49:00] <Lotte> (thanks for repeating, adding some sort of fancy highlighting to my wishlist)
[14:49:01] <Jiazi YI> hi
[14:49:03] <Lotte> perfect
[14:49:20] <thomas.heide.clausen> Lotte: seems that your RFC is on its way :D
[14:49:29] <Lotte> sorry Jiazi, I didn't want to prononuce yout name incorrectly, didn't mean to insult if it sounded like that :(
[14:49:47] <Jiazi YI> don't worry. I know it's not that easy :)
[14:49:50] <Lotte> Honestly, that sounds like a fun summer exercise
[14:49:58] John Dowdell leaves the room
[14:50:08] l-duehrsen leaves the room
[14:50:12] yuichi.igarashi leaves the room
[14:50:23] <thomas.heide.clausen> You and mr. Farrel will have a fun summer, then ;)
[14:50:23] leaves the room
[14:50:36] Jiazi YI leaves the room
[14:51:24] wetter leaves the room
[14:51:52] adrianfarrel leaves the room
[14:52:31] Lotte leaves the room
[14:52:56] bebemaster leaves the room
[14:54:39] teco.boot leaves the room
[14:54:49] benoit.claise leaves the room
[15:04:10] adrianfarrel joins the room
[15:06:00] Lotte joins the room
[15:07:54] teco.boot joins the room
[15:11:33] adrianfarrel leaves the room
[15:17:24] teco.boot leaves the room
[15:21:50] Lotte leaves the room
[15:35:59] jpmacker leaves the room
[15:37:06] teco.boot joins the room
[16:18:47] wetterfrosch joins the room
[16:19:25] wetterfrosch leaves the room
[17:14:06] jpmacker joins the room
[17:27:38] teco.boot leaves the room
[18:37:28] jpmacker leaves the room
[18:51:42] thomas.heide.clausen leaves the room
[19:01:43] teco.boot joins the room
[20:35:19] teco.boot leaves the room
[20:35:33] teco.boot joins the room
[20:36:01] teco.boot leaves the room
[23:43:22] wetterfrosch joins the room
Powered by ejabberd Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!