From: Pete Resnick <presnick(_at_)qualcomm(_dot_)com>
...
in his assessment): It's not my regular DSL network connection which
I use when I'm at home, but my connection back to that network when I
am using my Handspring Visor on the road. I've got a maximum 14.4kbps
connection over my mobile phone back to my home network. So, even if
life were perfect, on the hectic days of 50 messages at 4K a message
(200kB or 1.6Mb of data), that's about 2 minutes of download time per
day. ...
There are many obvious solutions to that and similar problems that do
not require waiting for other people to do anything, or imposing
on them to do it. One is to subscribe with that regular DSL network
connection and use the recently offered to forward the desired
subset to the Handspring Visor.
... (It would solve my problem I could do server side
filtering. For assorted reasons, I can't.)
I cannot conceive of any legitimate reasons to not be able to do server
side filtering. It might be impossible to get other people to install
filters at qualcomm.com or elsewhere, but that and similar reasons do
not make it a big deal to run free software on an old free or nearly
free junk PC running sendmail and procmail on a free UNIX box.
No, lack of technical experience doing such things or time to do
them is not a legitimate reason for demanding extra service from
others who receive no payment.
...
interesting question is the hit the secretariat takes. Even if there
were only 1000 subscribers to IETF-Announce, that's 200MB of data on
the busy days. However, my guess (and the secretariat can give us the
real numbers) is that that number is at least an order of magnitude
too low.
That number could also be an order of magnitude high if the IESG is
running sendmail or another MTA that does the obvious with batches of
addressees all with the same next SMTP hop. It seems plausible that
many subscribers share ISPs. Judging from Received lines, I think the
IESG's software can do the right thing in such cases.
Instead of counting (or guessing) bits, it would be more interesting
to look at the queue wait times. For example, if the Secretariat has
a T3, then even 2000 MByte per busy day does not matter. Only if it
takes more than perhaps about a day to finish a batch of announcements
does the load matter. From the durations of the big bursts of I-D
announcements that I see, I doubt this is a problem that needs solving
or that would not be more than counterbalanced by the hassles of
running more mailing lists. Besides the work by the computers, having
more lists inevitably means more chances for error, for more I-D
announcements to be lost or misplaced. If you actually pay attention
to any I-D announcements, you've noticed a error rate that is a
significant fraction of a percent.
...
people would subscribe to get all of the I-D announcements. Given the
low investment of time it would take to test this out, I think it
would be worth attempting it.
Investments imposed on other people are usually low enough to justify
themselves in the estimation of those doing the imposing, not matter
what those paying the taxes think.
Besides, it has already been more than "attempted" by a third party.
Vernon Schryver vjs(_at_)rhyolite(_dot_)com