|
Grex > Coop7 > #93: Protocols to be permitted when the kernel mods are rewritten. | |
|
| Author |
Message |
srw
|
|
Protocols to be permitted when the kernel mods are rewritten.
| 
Sep 1 06:09 UTC 1995 |
Last summer, the Grex membership voted a new internet policy into existence.
Due to the disk bug, staff has not spent any time developing the changes
needed to implement the new policy. I am entering this item to recap
what was voted on and to see if we can fine tune it as the staff considers
actually implementing this policy.
As I recall, the policy would permit unrestricted use of selected tcp/ip
protocols. These were (1) Finger, (2) Talk, (3) Gopher
Does anyone remember if there were any others opened up to unrestricted
use?
The vote also loosened the restrictions on usenet, but that is academic
as we don't have meal plans yet.
I believe that the nature of the net has changed dramatically since then,
and I believe that http protocol should be added. I would like to propose this
idea to the board to consider at the next board meeting. Until then,
I entered this item to provide a place to discuss this question.
|
| 27 responses total. |
steve
|
|
response 1 of 27:
|
Sep 1 11:24 UTC 1995 |
The question is, how much of a benefit would it be to people
to have lynx available, and how much of a drain will it be to
the link?
I'd like to open it up as much as possible, but if we
get so bogged down with all the link trafffic that people
find the throughput unacceptable and leave Grex, then we've
made a bad decision.
|
popcorn
|
|
response 2 of 27:
|
Sep 1 12:13 UTC 1995 |
Hm. People can use lynx from elsewhere to get to Grex, and then use
a link on our homepage to telnet to Grex. Would opening up http use
allow people to also use telnet, via links on web pages?
|
srw
|
|
response 3 of 27:
|
Sep 1 12:15 UTC 1995 |
Link throughput is a non-issue since http traffic is given very low priority
by the router. My preference is to increase its priority on the router,
but that is a topic for another item. Unless we do that, I can't understand
how it can bog anything down except other http traffic.
I believe that http and gopher are very similar in the users' minds.
Gopher was opened up by the members when they voted. I am trying to
determine if they would have voted to include http in that. It just
didn't come up at that time,. I believe, but today I think it would have
been part of the package.
|
srw
|
|
response 4 of 27:
|
Sep 1 12:19 UTC 1995 |
Valerie slipped in ... no Valerie .... opening up http would allow
non-members on Grex to see web pages elsewhere on the net. It would not allow
them to use lynx (or any other client) for other protocols such as
telnet or ftp.
The Kernel blocks operate on a protocol basis, not a client basis.
In fact, lynx will be able to see gopher pages as soon as the kernel
blocks are loosened to permit this.
|
srw
|
|
response 5 of 27:
|
Sep 1 12:22 UTC 1995 |
The members also included Ping - which I forgot.
The vote also mentions other protocols ... Archie Veronica and WAIS,
but I am not certain that these are actually protocols. The full list
is given in /usr/local/grexdoc/archives/prvote/prvote02
|
remmers
|
|
response 6 of 27:
|
Sep 1 16:13 UTC 1995 |
Hmm, I had thought that the proposal included some language
allowing the Board to open up additional protocols without
resorting to a member vote. But in reading the proposal again,
I don't see such language--the only discretion given the Board
is for emergency situations or instances where some provision
is technically impossible to implement.
So I'm wondering if another member vote is necessary to add
http.
|
rcurl
|
|
response 7 of 27:
|
Sep 1 17:29 UTC 1995 |
It might be better to approach it, after all this time, as considering
a revised policy, which includes http. This would be so that the whole
"package" can be viewed and considered at once.
|
ajax
|
|
response 8 of 27:
|
Sep 1 19:05 UTC 1995 |
Out of curiosity, is srw's proposal for unrestricted http access an easy
change, or is it a long-term project like providing unrestricted "finger?"
|
steve
|
|
response 9 of 27:
|
Sep 2 04:00 UTC 1995 |
The new system for kernel blocking still has to be done.
Forunately it isn't too hard. Adding or deleting something
from that list of allowables is easy.
|
srw
|
|
response 10 of 27:
|
Sep 3 02:30 UTC 1995 |
I don't see why it would require a member vote to add http. The board could
authorize that.
|
rcurl
|
|
response 11 of 27:
|
Sep 3 07:35 UTC 1995 |
Steve is right - the board can make policy too. The original policy that
was developed and then voted upon in coop could also have just been
adopted by the board. However a member vote was a logical course for the
first draft of the policy, since it is relatively complex and affects all
users. Remmers may be thinking that since the original policy was adopted
by vote of the members, it should also be amended that way, although there
is no requirement for that in our bylaws. I think, that since what is at
issue here is adding another mode - http - to what was a liberalizing
policy, maybe no one would object, which would make a board vote the
simplest procedure. Does anyone object?
|
lilmo
|
|
response 12 of 27:
|
Sep 3 19:39 UTC 1995 |
I think it would be only fair for the board members, before making such a
move, to at least make an effort to get the sense of the membership. (And
I say this as a non-member not expecting to have a voice in the decision.)
|
davel
|
|
response 13 of 27:
|
Sep 4 00:37 UTC 1995 |
Mark, anyone who takes the time to post in coop has a voice in such
decisions. If it's a membership vote on a policy (as was the case with
this one, originally) only the voters get a final say, so to speak, but
many of them definitely listen to, & are sometimes convinced by, non-
members who speak up.
|
kaplan
|
|
response 14 of 27:
|
Sep 4 03:14 UTC 1995 |
As a regular member but not a board member, I'd say staff can open up http
to non-members with the sun4 upgrade without bothering with a membership
vote specifically on the http question.
But the vote that we're talking about implementing took place such a long
time ago, I wonder if we shouldn't throw it out and take a new vote on the
entire issue.
|
rcurl
|
|
response 15 of 27:
|
Sep 4 07:08 UTC 1995 |
In a post just a little while back I suggested at least reposting the
policy, so we could have another look and decided whether it needs
any other tinkering. I would not suggest a new vote on the entire issue
unless extensive fixing seems necessary.
|
popcorn
|
|
response 16 of 27:
|
Sep 4 12:33 UTC 1995 |
I agree. The vote took a lot of time and energy, the last time 'round.
|
chelsea
|
|
response 17 of 27:
|
Sep 4 14:04 UTC 1995 |
The policy:
PROPOSAL:
The following internet services enrich the Grex community, do not use
much bandwidth, and do not provide much potential for internet
mischief; therefore they should be made available to all:
Finger
Whois
Ping
Mail (incoming and outgoing)
Incoming Usenet News
Incoming Telnet
Incoming FTP
Incoming Lynx
Talk (and it's various permutations)
Archie
Veronica
WAIS
Gopher (with all Telnet capabilities disabled)
The following services will be restricted to VERIFIED GREX MEMBERS and
VERIFIED GREX USERS (however the board shall define that term) because of
the potential for world-wide mischief:
Outgoing Usenet News
The following services will be restricted to VERIFIED GREX MEMBERS in good
standing, because these services utilize a lot of bandwidth, offer
less of a benefit to the Grex community as a whole, and/or hold the
potential for system cracking and other undesirable activities:
Outgoing FTP
Outgoing Telnet
Outgoing Lynx
Gopher (with telnet capability enabled.)
IRC
Being that the major objection to open access for the above
services is the lack of available bandwidth on Grex's internet
link, It is understood that any of these services may be made
available to all VERIFIED USERS as well as VERIFIED MEMBERS as soon as Grex
acquires a link of suitable power and robustness.
In order to maintain the integrity of both Grex, and of the Internet as a
whole, the Grex board shall have the power to restrict or deny internet
access to groups or individuals who pose a security risk, or who engage in
inappropriate behavior (as defined by the Grex board).
The board may also make modifications to this proposal without resorting
to a member vote in the case of an emergency situation, or if some
provision of this proposal proves to be technically impossible to implement.
VOTE RESULTS:
Results were posted on Wednesday, August 17, 1994.
49 out of 80 eligible voters cast ballots. The Tally: Yes 36 No 13
The proposal passed.
|
rcurl
|
|
response 18 of 27:
|
Sep 4 17:46 UTC 1995 |
So, is adding http an emergency situation? The fact of the matter is that
no "motion" adopted by either the members or board can constrain
subsequent motions adopted by the board. Only bylaw amendments can do
that. That is, if the board votes to add http, it's added, even though that
case is not covered in the policy. My preference would be to remove that
last paragraph since the board always has that power and more.
|
srw
|
|
response 19 of 27:
|
Sep 4 19:06 UTC 1995 |
I agree completely.
|
remmers
|
|
response 20 of 27:
|
Sep 4 21:48 UTC 1995 |
Well, I see that "outgoing lynx" is one of the protocols mentioned
explicitly in the list of things that may be extended to all verified
users at the board's discretion. Since "outgoing lynx" is simply
inaccurate terminology for "outgoing http", there appears to be
no problem.
I *would* have a problem if the board undertook to enact something
that violated the spirit of a proposal passed by the members.
|
rcurl
|
|
response 21 of 27:
|
Sep 5 06:05 UTC 1995 |
I would too, at least without full discussion (everyone can change their
minds).
|
srw
|
|
response 22 of 27:
|
Sep 5 06:30 UTC 1995 |
I would too.
I was proposing outgoing http for all users, not just verified ones.
Same as outgoing gopher.
|
popcorn
|
|
response 23 of 27:
|
Sep 5 11:56 UTC 1995 |
I would too.
|
selena
|
|
response 24 of 27:
|
Sep 5 19:06 UTC 1995 |
Hm. If privileges can be revoked because of security reasons,
can they be extended for "good citezens"?
|