Sent from my iPhone > On Nov 4, 2015, at 10:11 AM, John C Klensin <john-ietf@xxxxxxx> wrote: > > > > --On Wednesday, November 04, 2015 21:15 +0900 Jari Arkko > <jari.arkko@xxxxxxxxx> wrote: > >> >>> Relative to the question I tried to ask via Jabber, my guess >>> is that Andrew and Jari were expecting questions to come in >>> via Meetecho, no one told them it was down or having >>> problems, and there was therefore no fallback plan such as a >>> designated Jabber scribe/channel who was logged directly into >>> the Jabber room. I tried getting the attention of a few >> ... > >> I'm sorry about this. That was my failure. > > Jari, > > Apology accepted but unnecessary. I am much more concerned > about our learning from the experience and making sure we have > enough backup mechanisms in place to be sure it does not happen > again. > > As one part of that, I have suggested to Simon that, if they > discover that their systems are not behaving in top form, they > take responsibility for being sure that whomever is chairing the > meeting or running the in-room mic queue is aware of the > problem. I suggest to you, Andrew, and WG Chairs that you be > sure that there is a "Jabber scribe" or designee in the meeting > room who is logged directly into Jabber (not via Meetecho or > other intermediary) and alert to system failures and > disconnects. It also occurs to me that there should be a > contact mechanism for the Secretariat and/or NOC that is not > dependent on the IETF Jabber servers (or, ideally, even the > Secretariat or meeting networks) being up. Yes, all of this, plus remote participants should join the jabber room before they connect to meetecho if they want to be sure to have chat capabilities. It's tougher the other way around and requires you breaking the meetecho session even if some parts are working. Meetecho sees your name in the chat room and adds a number to the end so you have 2 distinct connections. Kathleen > > None of those things would be necessary if everything could be > guaranteed to work smoothly. But, when Murphy's Law gets us, > understanding quickly that things aren't working well, being > able to compensate if feasible and to at least be aware of the > problem in real time, are important. > > I agree with Randy's unhappiness about what we are giving remote > participants, especially when things don't go completely > smoothly. We are doing, IMO, lots better than we were a few > years ago, but, as we continue to offer improved capability, we > also continue to raise expectations and dependencies on fairly > complex systems (systems that include the humans as well as the > software). > > best, > john > > > >