Remote Participation Services Requirements (RPSREQS) BoF IETF 83, Friday Paul Hoffman, Chair Minutes by Paul Hoffman (Text from the slides is not necessarily repeated) This work is part of the General Area Agenda was bashed Mailing list for this discussion: vmeet@ietf.org Draft for this work draft-ietf-genarea-rps-reqs -03 has been out for a few weeks, already have input for -04 Want a lot more input, will do a few more drafts There will be consensus calls on the list There will be an IETF Last Call for IETF consensus Run by Russ Housley, not Paul Randy Bush: I think the draft should be about four pages It is designing a whole bunch of crap on things for which we are incompetent It covers a lot of corner stuff it doesn't need to It should just say "as end users, we want to be able to participate remotely" Put up a short set of bullets, but no one responded Paul: Looking for input where at least a small number of people agree Bert Wijnen: We are getting more and more tools Instead of focusing on the WG meeting, chairs have to administer the tools We should not take the chairs focus from running the WG Randy is no longer on the mailing list Marshall will bring this thread to the mailing list Requirements instead of technologies This is not a protocol document, so its properties are different Eventual result will be one or more RFPs for the actual services based on the capabilities we require Ed Juskevicius: Anyone who has been to an IETF meeting will have a set of expectations for remote participation People who have never been here will have a different set of expectations Which set of users are we aiming at? Paul: See the last slide (not for answers, but for the question) Important difference between people who want to listen remotely and who want to participate remotely Focus is on participants, not passive observers Joel Jaeggli: Wrote an earlier draft describing the properties Also documented current tools Agrees that there is a distinction between remote viewer and contributor A "contributor" is someone who says something on the mailing list or in the meeting or on Jabber Someone who just reads and downloads is an "observer", maybe a "participant" Randy: Is amused that we are this far down the process without knowing who is the real target There is an underlying physics Wants someone to be able to chair remotely Joel: "Contributor" is the Note Well word, and we should use it Paul: Document is supposed to cover interim meetings, but not at the same level The document is for the future RPS, not what is supposed to be happening today Dave Crocker: Possible differences between an interim meeting and this one That kind of description is an organizing framework which helps to set expectations and give an integrated view So far, there are more pieces of requirements instead of an integrated view If there was sets of integrated views that created snapshots of usage and derive requirements from that, it would be more cohesive Integrated views are the hard part of the discussion Absent that, we are shooting around in different directions Michael Richardson: We are unclear on whether we are building requirements for interim meetings that have f2f or virtual meetings Facilitating more virtual interim meetings is a valuable goal Facilitating remote participation in interim meetings is very difficult If there was something to drop, drop the latter Joe Hildebrand: All-virtual meetings are easier to do than adding remote participation Paul: Since Taipei, there have been both virtual interims and face-to-face interims Two of the f2f interims had failure for remote participants Marshall Eubanks: Very different sociology between virtual meetings and f2f If it is entirely virtual, the virtual part has to work If it is f2f, local participants allow failure, but that's frustrating for remote users Paul: Capturing the cultural differences has been daunting Some WGs decide to only have virtual interims because of the cultural issues Some WGs decide to only have f2f interims because of the benefits such as side conversations Tiered requirements for new capabilities We have current tools, plus experimental ones such as Meetecho and WebEx Some capabilities are tiered by priority, with soonest-delivered coming first Want a list, need at least the first one first, and are happy if we get additional ones first as well The current draft has a few "functional specifications", but those will probably disappear Interactions with WG chairs How WG chairs run meetings is very important A tool should not get in the way of that unless it clearly helps Tools will be voluntary for chairs: use them if they help There will be effects both during meetings and between meetings Need to have provable benefit Wes George: How we facilitate the new tools? May need someone dedicated to each room who is responsible for facilitating all the tools Need to think about making this be transparent If we are expecting greater reliance on the tools, we have to deliver on that Some chairs want to delegate more than others Ed: Use of the tools will be optional? Paul: Yes, for most tools. Russ Housley: We don't know yet Paul: Wants them to be optional, but this should be in the document There are so many optional tools that different WGs have very different experiences Help chairs plan for the next meeting Checklist of the tools, and the WG chair picks the ones they will use Helps the Secretariat (and so on) set up the tool ahead of time What are the requirements to support the toolset? Paul: Depends on the tools chosen Marshall: Need a checklist or cookbook Paul: Next version of the draft will have things split out by task before the WG meeting, during, and after Should be as braindead as possible The checklist should generate a per-WG page that includes everything, including what to tell participants This will help us find out which things are really optional Paul: IESG will tell the WG chairs what they have to do to make the meetings effective Marshall: it will all shake out at the end Chris Morrow: Not sure why this is all so challenging If we are going to give people two or three more things, we have to make it braindead for a chair to know what they need All of this should be available before the meeting Make it cross-platform as possible Paul: Different WGs will be better prepared than others What we want is that the least prepared WGs aren't made any worse with the new tools Need to reassess if we do make it worse Randy: No 500 lb Java applet It might be 500 lbs, but it will be a disaster Henrik Levkowetz: Current spec is "we are going to put this tool in place and it will fix remote participation" We are looking enough at the tools that we already have such as Jabber and now Etherpad The world will move along and there will be better tools that come along We need to not think that we are going to freeze here Paul: A good example is when people on Weds wanted blue sheets for Jabber Peter St. Andre pointed out that Jabber can require certain logins Joe: Haven't gotten feedback to the WebEx product team Need to do this for all the tools so they can all improve Joel: We need to reduce the number of options to the point where everyone uses the same set of tools It's not about having a choice When we all do the same thing, it's much easier to meet our expectations, even when they are bad Paul Kyzivat: It has to be simple WG chairs need to remember to turn on recording, but they shouldn't have to remember Things like this is an impediment to the tools working Patrick (?): It sucks when you have to credential in It's a burden when you are driving 80 MPH and you want to listen in Dean Willis: Sometimes, we have just lost network We need a safety net so that we can still have a meeting even if the tools aren't working If all our our processes are tied to the tools, we might have to stop if the tools aren't working Target audiences for the document IETF community People who always go to meetings or never go to meetings WG chairs who host meetings with remote participants People who go to some meetings A sizable group of people go to one meeting a year Eventual bidders to provide the services More changes in the next draft to target them Can't assume that they have been to an IETF meeting, so they won't know what one is like Want to capture some of the culture without making the document too long Include a pointer to the Tao Brian Rosen: There is no section on the requirement on the suppliers We talked about that they must have people present, but there are other ones Maybe a requirement for the RFP is that bidders must have been to at least one IETF meeting Other similar requirements, such as that there might need to be a bakeoff Bob Hinden: IAOC will strongly encourage them to come to a meeting so that they know what they are getting into Marshall: There has been some recent press coverage of the IETF Bidders should know what they are getting into Next: open issues from the vmeet list recently Voice-to-room vs./and IM-to-mic Does the room hear her, or do we do something like today? Additional idea from Ray: copy and paste into a text-to-speech program that reads it over the mic Large split in opinions on this one Issues include simplicity, reliability, timeliness of communication, extra effort for chairs, effect on local participants There are culturally-acceptable ways to get attention in a room, but they are different for remote participants Very different effects for a scribe reading messages from a well-known remote participant than us hearing that participant Joe: Someone who says "mic:" on Jabber sometimes get more access to the room than people in the mic line Certain Jabber clients can look for keywords and alert the user SM: If there is also video, remote participants know where they are in line Joel: For WebEx, as the number of participants who can speak increases, the potential for disruption goes up faster In a telepresence rig, they can see each other so they tend not to talk over each other If you have people who are also just sound-only, you need to institute floor control Thus, you need to think about scale for remote participation So far, the number of remote participants is quite small per WG (like 4 to 10) For small-scale remote participation, our current conventions probably work fine If we go beyond this, we will need more tools (such as additional remote mic lines) Joe: An extra 20-30 milliseconds of delay radically changes interruptability, making it harder Humans negotiate subvocally about who will speak next Brian: Has done research on this (not published) Will send result to mailing list There is a cliff: if you have more than 150 milliseconds of delay, you cannot interrupt Dropping remote audio into a room is one of the hardest thing we can do: it fails more than it works It can still be valuable, but if it fails we need to be able to gracefully recover Marshall: The more structured the meeting, the less that the delay matters Human use cues, and if the delay is too long, we lose those cues Structured meeting with a chair that chooses each speaker can tolerate much longer delays Paul: Higher structure in the meeting is not part of the culture of the IETF My task was not to change the culture of the IETF Dominated by corner cases The IETF could change the culture without people taking offense Paul: Anything that involves changing the culture of the IETF needs to be discussed on the IETF list Joe: Echo fights with latency for solving the human interaction problem Joel: When using PSTN, you can sometimes need 2 seconds of buffer to fight echo Joe: Some echo cancelers max out at 80 ms Registration Local participants often know or recognize each other visually Local participants want to know who is participating remotely Natural human desire is to know who is listening Explicit request to not burden remote participants more than as if they were joining a mailing list Transparency of the process Blue sheet issues What would the remote participant have signed if they were in the room? We have a rule that the blue sheets are complete and correct, and we know we break that rule all the time Cost of the RPS will be addressed after we have a set of required capabilities Michael: Even though we are not going to discuss cost, we need to set MUST/SHOULD/MAY for features because of different costs Paul: The next draft will have leveling of proposed capabilities Russ: Please stop talking about cost. Cares about the requirements, and knows that there are many ways to pay for them Michael: Joining a mailing list today involves an echo check for email address and a password Paul: And it makes you look at the Note Well Joe: What about "here is a list of priorities"? Russ: That is exactly what we want, just not with cost considerations Bob: Agrees with Russ that cost should not be a priority, but we have to be realistic about what we specify Those considerations should be in scope Paul: It is out of scope until the IAOC tells me it is out of scope Marshall: It is out of budget Bob: Cost should not be a selection criteria for what the requirements are, but the cost could be a useful data point Paul: Useful for this document or for the discussion? Bob: Not sure Paul: As the document progresses, wants pointers to where cost discussion would be useful to the IAOC Bob: We are talking about requirements that have cost, so it's another factor in the way we look at them It's not the deciding factor Paul: Hearing different statement from Bob and Russ, unhappy John Klensin: Maybe have different registration for passive and active remote participants Joel: Dollar cost might be out of scope, but human capital is in scope Doesn't see those two as separable The number of contractors needed to run the tools, and the amount of work to run the tools, is in scope Last time he wrote a draft proposing something in this area, it was needed Don't think that "how you fund it" is related to "what it costs" Brian: The more bandwidth you can send it, the more we care about who you are If you are just watching text, we don't care who you are If you just send text, I don't care so much who you are, but if you can send audio/video, I really care who you are The authentication requirements for sending text are different than those for audio/video This affects the level of registration One of the ways to improve authentication is to have some cost associated with it Peter: Thinks Brian has it totally reversed We can identify John if we hear him on audio, but if it is just someone in IM, we want more authentication Joel: All contributions are contributions, so we have the same attribution requirements for all of them Question is not authentication: we have to do that Question is whether we have same authentication requirement for voice/IM contributions as we do in the room Question is quality of service and access control We should be authenticating everybody regardless of how they contribute Question is gaining access to the floor Voice and video are potentially more disruptive, and require floor control by the WG chair Marshall: We're an open standards organization For that to work, the IETF needs to know who the contributors are Joel: Current criteria used for authentication is considered sufficient Dave: We have had some accountability requirements for face-to-face meetings and mailing lists for a long time We assume they are OK For remote participation, we have had a different set of requirements As remote participation becomes more formally integrated as being real membership in the meeting, assuming alignment of registration We have an obligation for accountability We need to do registration that gives some validation of an identity We have a model of validation that is not stringent We need to set down the model for the future, but assume it will vary over time SM: Is jck.ietf@gmail.com adequate? Randy: Can't we leave this for Jorge Contreras? Us working on defining identification has no termination Dean: Managing registration for someone who comes in through the telephone is really problematic Integrating people on telephones with the Internet doesn't really work that well Is supporting remote participation by telephone an absolute requirement? Can we require a broadband Internet connection? Dave: Thanks Dean for raising a mode-of-use question Gets to core issues that will affect many requirements Tempting to say "everyone needs to be on the web" and everything flows from that It is not a practical mode for many situations It is unsafe for us to demand such a pristine world given the number of times someone has needed to phone in Excluding telephone access will be crippling Marshall: Requiring broadband access is a non-starter Area director in an airport who is only near a phone We keep trying to get people in places such as Africa involved: they might not be physically able to get to broadband Dean: "Broadband" was a bad term to use: he meant "Internet connection" VoIP might be sufficient PSTN through a gateway causes many delay issues that are a recipe for disaster Face-to-face interims without remote participation It was surprising to some people that this is considered OK People think hard about time and money costs Randy: Can we separate the rule-making from making it easy to do so Having interims without remote participation is OK, but we should try to facilitate remote participation It needs to be easier to hold one Michael: Was at an interim last fall where remote participation was supposed to be available The network was almost a complete failure As a result, half of the subsequent meeting in Taiwan was spent going over the results from the interim If no remote participation was available, more people would have travelled Paul: We need to decide if the tools that will be available will help face-to-face interims But we do not get to say to WG chairs how that affects whether or not they use the tools Ed: Less difficult to make remote participation work if you know well enough ahead that you are going to try to do it There could be a requirement that allows the WG chair who knows ahead of time to prepare better "If you want to use this tool, here is what you will need" Standards compliance Currently says that the specifications SHOULD rely upon IETF... Should this be a MUST? Video Very useful for the cultural cues we have talked about Takes up screen real estate both locally and remotely Technically challenging Comments I have heard this week [ Lots of stuff listed on five slides ] Ed: For all participants: what tools will I need and how do I prepare for them? Goals of this work Improve the effectiveness for the current set of remote participants Help people who are currently only mailing list participants become remote participants Targeting people who already know our tools is different than targeting new participants Reduce the perceived need for some people to attend some/all IETF meetings Probably other goals as well Open mic Randy: Speaking for those who are not here today Telcom regulators, people who feel disenfranchised by language differences These are participants whom we should be encouraging It helps them to see the English transcription scrolling It behooves the IETF to look much wider in scale, to be much more open, more inclusive IETF must play on a much more global scale Joel: Mechanisms that we have for providing feedback are inadequate There is a single escalation point for all initial problems: a service desk mtd@ietf.org The people who run that have good contacts for all escalation Odd that WG chairs feel like they need to do the escalation themselves There are different people in the escalation path every time, so knowing them is impossible Maybe the service desk also needs to be available on Jabber and PSTN Worked this week Should be a requirement for how the IETF works generically; already been handled Tony: The meetings that worked well with a running log on the screen at the front were the ones with restricted interactions with remote participants Paul: If we want to do this, there are a lot of requirements around it Different view than what Jeff said on vmeet list, want to see more discussion Dave: The dynamic in the WG Tony was speaking about was distinctive in that it was small, loosely run Friendly to a looser style For larger groups with more tight control, projecting Jabber or running notes on the screen does not contribute Jabber is useful regardless, but putting it on the screen is a style of operation for the room It's a presentation issue instead of a resource issue Information is available in various forms (voice, IM, ...) and different types of presentation For people who use English as a second language, slides available head and having Jabber is invaluable, regardless of if it is on the screen There is a mode of "remote meeting participation" that takes place in the room A functional spec is something that says "use Jabber" or "use voice" Meeting support is different Remote people need easier meeting support than locals do Reliability is key and will always be imperfect We need graceful degradation when tools fail Plan for reduced capabilities, both when things break and for people coming in on a thin wire If designed in, will probably be easy to support and will give a better experience Sébastien Balchollet: Wants us to get input from other SDOs Many (ISOC, ICANN, ITU) have their own remote participation tools On the board of ICANN, is trying to help the remote participation at ICANN meetings IETF can learn from ICANN, ICANN can learn from IETF Was interested that there was more talk about cross-platform than interoperability End users need to learn each tool, which differ in different SDOs We need to focus on how the end users will use and learn the tools Adobe Connect puts all tools on one screen, which has problems with size but ease of learning Maybe have a requirement that helps translation of presentations to help users Should have a cross-organization discussion SM: Can we have the transcription service in every WG meeting? John: Can we have someone monitoring the mic gain in every room? Having slides in advance lets you look ahead and behind at the slides Ed: Is there a requirement for a tool that enables hums? Paul: We have a requirement for polling, not hums If I am chairing a meeting remotely, how do I call for and monitor the hum