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 'service' 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_aboba@xxxxxxxxxxx> 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. |