[rfc-i] rfc-info needs your help!

Alex Rousskov rousskov at measurement-factory.com
Fri Apr 9 19:47:55 PDT 2004


	We should probably close this thread until real users with
real needs show up so that RFC Editor can evaluate their needs in
relation to RFC Editor resources and priorities. There seems to be
little information trickling in after the initial exchange. I suspect
we are annoying RFC Editor folks more than helping them at this

If you feel strongly about your points, please find a different
opinion below...

On Sun, 4 Apr 2004, John C Klensin wrote:

> --On Wednesday, March 31, 2004 Alex Rousskov
> <rousskov at measurement-factory.com> wrote:
> > IMO, RFC Editor should not be in business of providing backdoor to
> > those who try to circumvent local policies (even if those policies
> > are considered evil by IETF majority). Others like friends and
> > colleagues abroad can provide such backdoors.
> Sorry, but the above would be reasonable if there were strong
> evidence that the blockage was an intentional and accurate
> implementation of local policy.

The above assertion was not meant to cover all cases.

> But the vast majority of these blockages which email can get around
> fall into one of two categories...
> (1) A policy is implemented in a way that blocks facilities and
> information to which the policy doesn't actually apply, at least
> intentionally.  This case is pretty common and we are not helping
> someone "circumvent local policies" but to work around an intended
> bit of wrong-coding over which they have no control.

IMO, RFC Editor should not be in business of providing backdoor to
those who try to work around unintentional blocks and

> (2) A policy, possibly by the individual trying to obtain the
> information, that recognizes the existence of time-of-day pricing,
> or high prices for "online internationally" time on Internet access
> and/or mail gateways that are set up to let large files through only
> when critical links are not seriously congested.

HTTP downloads are easily scheduled for times when the price is low
and large downloads are easily split into small ones to be
auto-assembled at the client side. The problems you are referring to
are old and real. They have old and real solutions that do not have to
involve RFC Editor as long as RFC Editor is providing a well
functioning HTTP access to RFCs.

> "Send this to me by mail" automatically handles the latter and may
> help considerably with the first.

... but does not have to be the service offered by overloaded and
resource-lacking RFC Editor, IMO.


More information about the rfc-interest mailing list