ietf
[Top] [All Lists]

Re: charging remote participants

2013-08-28 04:59:11
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_aboba(_at_)hotmail(_dot_)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.                       
                 
<Prev in Thread] Current Thread [Next in Thread>