Hi Bernard, I'm afraid that, as it usually happens with 'software', we are overly underestimating the huge development effort (in terms of human resources and brain cycles) that is needed before arriving at a 'few hundred $ per year' product. When it comes to the IETF, let me also add that, in my honest opinion, no existing product can simply be taken from the market and brought to our community. There's a significant effort associated with the integration with a whole bunch of tools (meeting materials page, agenda, etc.) which are already available. Not to mention the deep knowledge of all IETF procedures and mechanisms required in order to organize and conduct a successful meeting. If you take all these things into account, you'll probably arrive at a much higher funding level than the one you envisage. I also believe that the time is probably ripe to stop the experiment-only phase and start to take seriously into account the fact that remote participation is in all respects a 'servic! e' that the IETF is going to offer to the community. Experiments have a well-defined time-frame; after such a period, they have to be declared either a success or a failure.
Just my 2 cents, Simon Bernard Aboba <bernard_ab...@hotmail.com> ha scritto: >Hadriel said: >"I agree. My proposal for how/what/where to get more revenue (and not >from remote participants) was only in case we actually need it to pay >for enhancing remote participation. It's not clear we have such a need >any time soon, but I was only trying to provide an alternative model to >charging remote participants. " [BA] It appears quite possible to >significantly enhance remote participation in the IETF with minimal >funding. The load pattern of the IETF (heavy during physical meetings, >much lower in between), accommodates itself well to the use of cloud >services. - making it possible for the IETF to avoid having to purchase >hardware to handle the peak load, instead being able to scale up/down >capacity as needed. From what I can tell, the breadth and depth of >services obtainable for a few thousand $/year of expenditure is pretty >impressive. As an example, the cost of putting up an audio >conferencing service supporting Opus (usable by any WG that needed it >for virtual or design team meetings) would only be a few hundred >$/year, excluding the cost of PSTN connectivity. Even small scale >video conferencing doesn't appear to be very expensive. If there are >only a few video participants, it is possible to mix on the peer, and >for centralized conferencing, a "small instance" virtual machine (e.g. >one core, 1 GB RAM) appears capable of handling half a dozen >participants using software such as jitsi-videobridge, without breaking >a sweat. So, a thousand $/year might cover it (assuming that we aren't >attempting to provide telepresence-quality video). Even if money were >*really* tight, we could easily obtain donations to cover costs in that >ballpark. >IMHO, the hard problems relate to engineering, not finance. In >particular, the challenge is to provide a system with low >administrative overhead and good ease-of-use, integrated with IETF >processes. To advance the state of the art, IAOC RPS committee (see >http://iaoc.ietf.org/committees.html#rps) will continue to sponsor >ongoing experiments at meetings, as well as pilot tests. >
