By the time I completed my first pass through the document, Fred Baker <[email protected]> had written: > > A general comment throughout at least section 4 and perhaps the > entire document - could we use RFC 2119 language when we're talking > about requirements?
A very good point! It appears we have some actual MUSTs and a whole bunch of SHOULDs. > My first thought is that we should specify things we know we will need; > it is possible to over-specify to the point that no product (vendor > or open source) meets the needs. I'm not greatly worried whether any current product meets the needs: I'm satisfied that all the ones I've experienced need work! > "It would be nice to have floor control" makes sense, but I think the > real requirement is that the host for the call, whatever one calls > him/her, should be able to mute someone that can't or won't mute > themselves. It's pretty unusual to have a floor fight over the > microphone in the IETF. Clearly, the ability to mute someone who can't or won't mute himself is a MUST; but I would claim the MUST goes farther than that: even soft room noise from a non-speaker can be very distracting. >> 3.3. Remotely Speaking at the Mic >> .... >> o [[[ TODO: More here, of course. ]]] > > IMHO, "more here" is the wrong answer. I agree with Paul, not Fred, here. I understand Fred's frustration with two pages of examples where the casual reader gets the roles hopelessly mixed up; but IMHO these examples need to be documented to understand how really poorly our current system of "channeling" works. > Instead of spending two pages on examples, we need to simply say > that we need a way to facilitate remote speakers speaking for > themselves. The MUST, IMHO, is that remote participants MUST be able to speak directly and be heard by all participants, whether local or remote, subject to scheduling by the Chair. Some possible SHOULDs: - a remote participant SHOULD be able to provide real-time video while speaking. - the audio fed to a remote participant SHOULD exclude his own voice, but enable him to hear any questions raised by what he says. (This probably needs wordsmithing -- the extent of excluding his own voice varies greatly depending on how he hears it.) - there SHOULD be a clear signal that it's time for the remote participant to start and/or stop speaking. - the audio a remote participant receives SHOULD not be delayed by more than one second from the audio in the meeting room. - when network issues interrupt a remote speaker, there SHOULD be a clear indication to local and remote participants that this is the reason for the silence. - there SHOULD be a real-time display identifying remote speakers. - remote participants SHOULD be able (if the Chair consents) to ask questions of the other speakers without tool-imposed delays exceeding two seconds. - there SHOULD NOT be any reason to delay the start of a meeting to get volunteers to facilitate remote participation. - it SHOULD be possible for two or three remote participants to speak at the same time, interacting without tool-imposed delays exceeding one second. - there SHOULD be a mechanism for remote participants to notify local speakers that the audio quality is inadequate. >> 3.4. Chairs and Floor Control for Remote Attendees >>... >> o [[[ TODO: More here, of course. ]]] > > It seems to me that the fix for 3.3 fixes this as well. But this > doesn't address floor control (Alice is eating a sandwich and > slurping soda at her mike and the chair wants to mute her, > Bob is talking right over someone else, ...). I'm not sure that's "floor control" -- there's a need to recognize that remote participants can't always tell how disruptive their room noise would be; and "floor control" is the typical tool to ameliorate such problems. "Floor control", IMHO, is really about scheduling speakers in a manner which appears "fair enough" to all participants. One tool not mentioned is to formalize a display of "Joe first; then Bob". > Collapse this into 3.3 and then insert a section on floor control. Fred may be correct that these examples belong under 3.3... >> 4. Requirements for Supporting Remote Participation in Face-to-Face >> Meetings >>... >> **Requirement 00-01**: The specifications shall rely solely upon IETF >> and other open standards for all communications and interactions. >> (This requirement comes from [RPS-RFP].) > > So - no solution we have tried since the MBONE actually meets the > requirements. I would not dismiss this as "they just want to be > proprietary". The IETF has not served itself well if it doesn't take > time to find out what the various solutions needed that IETF and > other open standards didn't provide. This objection, while valid, seems out-of-scope... >> **Requirement 00-02**: All tools in the RPS must be able to be run on >> the widest possible array of computers. This means that they must be >> able to be run as an application, from any modern web browser, or >> from the command line of all of (at least) MacOS version 10.6 or >> later, Windows 7 or later, and any common Linux distribution produced >> in 2010 or later. >> >> [[[ TODO: Do we need to include IOS and Android platforms in that >> list? ]]] > > Well, not handheld telephones, but iPad and equivalent. Those strike me as low-level SHOULDS, barely exceeding "would be nice" for what we're specifying here. I'd even back off on the "any common Linux" for the first pass. Eventually, of course, we'll have to do Android; but at first we'll probably only support common Browsers on common platforms. >> 4.1.1. Audio >>... >> **Requirement 00-04**: Remote attendees must be able to speak >> directly to a meeting without going through a local attendee, and >> have their speaking be heard by local attendees. (Note that the >> ability to speak is controlled by the chair; see Section 4.2.2.) >> [[[TODO: is there a requirement that remote attendees who speak be >> registered as in Requirement 00-30 and Requirement 00-31? ]]] > > This has more to do with the IETF funding model and IPR models than > anything. IMHO, anyone who "speaks" should be identified as part of the record. I'm not sure funding issues belong in-scope; and I'd rather not confuse folks with IPR models. > The funding issue is that the IETF is largely funded through > attendance fees; presumably there would be a fee associated with > registration. True, but out-of-scope IMHO. > The IPR issue is that if someone is "in the room" (eg has signed the > blue sheet) when an IPR-related topic is discussed, that has legal > ramifications later. True, but confusing. There is a definite "blue-sheets" issue, which probably deserves a Requirement (though I'm not sure what it might be). > What if they're on the audio stream? I think the answer needs to be > "yes", To me, anyone who speaks should be "registered", but someone who only listens and follows slides isn't obviously different from one who listens to the recording later. > but I personally would be very happy to see it done though putting > one's email address into a web page and receiving a URL in a > responding email that is correct for the audio from the room. Works for me... >> A common complaint with the current RPS is that the streaming audio >> can take more than 10 seconds (and sometimes as much as 30 seconds) >> to reach the remote attendee. This causes many of the problems >> listed in Section 3.3. >> **Requirement 00-05**: Audio going to and from remote attendees >> must be delivered in as close to real-time as is practically >> possible. I'll break in here... My intuition is that there's a MUST here, of the nature of - audio delays MUST NOT be more than 500 milliseconds greater than the network delays. >> **Requirement 00-06**: Audible echo must be damped or eliminated >> by the tools. This exceeds the possible, in a system with jitter (which we can't avoid). OTOH, audible echo delayed one second or more is incredibly distracting. And two or three echos of varying delays can render a conference impossible to follow. I think the requirement is more like - the tools MUST recognize audible echo, and SHOULD automatically take measures to reduce it to a level which won't distract listeners. >> 4.1.2. Video >>... >> **Requirement 00-10**: Remote attendees need to be able to see the >> presenter at a meeting. >> **Requirement 00-11**: Remote attendees need to be able to see local >> attendees at any mic in the meeting. >> [[[TODO: Is there a requirement that the remote attendees see the >> slides over video? ]]] > > ..."SHOULD" be able...? These three feel like SHOULDs to me, with seeing the slides exactly as presented being the closest to a MUST. (It seems the easiest, and getting out of sync with the slides is a _serious_ impediment.) >> **Requirement 00-12**: Remote attendees who are speaking over the >> audio must be visible to the local attendees. > > well, "IF the remote attendee has appropriate supporting infrastructure". > If the guy's in an airport calling from his mobile phone... That's a very real consideration (though hopefully it's not _usually_ an airport). To me the requirement is - all participants MUST have a means of recognizing who is speaking remotely, and SHOULD be able to see video provided by the remote system. >> **Requirement 00-13**: Video going to and from remote attendees must >> be delivered in as close to real-time as is practically possible. > > I blow two ways on this. I understand what you're saying, and I agree. Video generally can tolerate a several-second delay; and I wouldn't hold it to the same standard as audio. > That said, when we had a 30 second feed delay in a streaming media > path I doubt that anyone thought that was a good thing or intended to > make it happen - it was in that configuration "as close to real-time > as [was] practically possible". Alas! that's true... > I think you need to say something testable, and say how to fail the test. Indeed. (And that's why I think we can only specify non-network delay.) >> [[[ TODO: Is there a requirement that IETF video integrate with the >> venue video, if any? ]]] > > "SHOULD"? I don't think there's such a need; but it would be nice for the IETF video to be available on local laptops. >> [[[ TODO: If video is provided, is there a requirement that it be >> archived and accessible? ]]] > > IMHO, while video improves the human experience, there is no information > conveyed about the meeting that can't be reconstructed - slides, > documents, jabber logs, and audio. After the fact, I consider it "nice > to have". I mostly agree; but I think we need a strong SHOULD about recording slides as presented. >> 4.1.3. Instant Messaging >>... >> **Requirement 00-18**: The instant messaging channel needs to be >> useful for humming, which is the common IETF method of assessing >> support. > > I understand the goal, but I'm concerned about the implementation. The problem here is that "humming" needs a definition. To me, a "hum" button separate from a "raise hand" button is called for. > Suggestion: "The IM Channel must facilitate straw polls". Good to talk about "straw polls" in order to clarify that it must be clear what is being hummed. Less good to suggest that the _tool_ should constrain how we hum. >> 4.1.4. Slide Presentations >> >> **Requirement 00-19**: The input format for slide presentations must >> be either PDF or PowerPoint. PowerPoint is inadequately defined. (Actually the PDF definition is also deficient, but only a little.) I'm not sure what this Requirement intends. Folks _will_ show up with PowerPoint slide-sets; and I suppose it would be good if the tools we use accept these about as well as a WGC's laptop would... But the real issue is that remote participants should see the same video that local participants do. >> **Requirement 00-20**: Presenters must be able to update their slides >> up to just before their presentation, if such update is allowed by >> the chairs. I have seen many cases of updating slides _during_ the presentation. This doesn't feel like the right Requirement... >> **Requirement 00-21**: Chairs must be able to approve or >> disapprove of any slide submission or updates, with the default being >> that all submissions are allowed. > > Speaking as a chair, anything that helps me say "I actually don't have > the capability to accommodate that request" helps me in dealing with > people who pull stunts like this. These Requirements as currently worded don't seem helpful enough to overcome Fred's reluctance. >> **Requirement 00-22**: It needs to be clear to the remote attendees >> which set of slides is being currently shown. >>... > > If the slides are visible as presented, that will be met. My question > is: is there a requirement for the speaker to select slide order in > real time? Absolutely! >> [[[ TODO: If the slides will be visible to remote attendees as they >> are presented, is there a requirement that presenters be able to use >> the equivalent of a laser pointer? ]]] > > I would note that as "nice to have". I don't think this rises to the level of SHOULD. >> [[[ TODO: Is there a requirement that animation in PowerPoint be >> supported, or just static slides? ]]] Many presenters won't accept a rule against animation. > There are arguments on both sides there. If you force pdf, there is no > animation. On webex, if you share the ppt application you get animation, > but there is another mode in which you get a static version. I would > list it as "nice to have". It comes down to what we mean by "supported"... To me, the requirement remains "visible to remote participants as presented". >> 4.1.5. Shared Document Editing Fred raises good points, but I won't comment on them. ==== I have a bunch of scribbles which don't seem important enough to add here. I will note that Requirement 00-33 probably doesn't need to specify "the IETF Secretariat". In Requirement 00-43, I'd add that actually turning on "all mikes" is often a bad choice. It kind-of works for IESG sessions, but there are a number of instances where the flow is interrupted by "Alphonse and Gaston" moments. It's the best-choice of those available, but it's easy to imagine better choices. More particularly, "all mikes" picks up entirely too many extraneous sounds, and (when it gets "bad enough") everything stops to diagnose which mike(s) are responsible for the worst distractions. In Requirement 00-45, I think it unwise to specify a particular authentication method. In Section 4.4, I think it unwise to set an expectation that remote participants will be recognized to speak, since there may be many, and _they_ aren't anxious to get to dinner. ;^) -- John Leslie <[email protected]> _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html. https://www.ietf.org/mailman/listinfo/vmeet
