Article View: comp.admin.policy
Article #46Re: DRAFT Student Access/Use Policy
From: John Hascall
Date: Mon, 13 Apr 1992 14:27
Date: Mon, 13 Apr 1992 14:27
135 lines
7060 bytes
7060 bytes
When last we left our intrepid explorers... morgan@ms.uky.edu (Wes Morgan) writes: }john@iastate.edu (John Hascall) writes: }>morgan@ms.uky.edu (Wes Morgan) writes: }>}I have been working on a "Student Access and Use Policy". I've finally }>}managed to wrangle it into a manageable form. I'd like to hear any com- }>}ments you may have. }>}1.2 Sharing your userid with any other person is prohibited. [Paragraph }>} 1.21u, CSC] }>} }>}1.3 Using a userid which belongs to another user is prohibited, even if you }>} have been issued a userid of your own. [Paragraph 1.21u, CSC] }>We also have a rule of one userid per person -- it sounds like this is your }>situation, maybe that is worth saying explicitly. }That is mentioned explicitly in the "rationale" section preceding these two }points. Are these two rules *that* unclear? How should I rephrase them? Well, here at least, we have a number of people who keep asking for another userid for some purpose -- we don't do this. This is what I was wondering about. }How about something like this? } } "Use of ECC facilities and/or services for explicitly commercial } purposes is prohibited. ECC facilities and/or services may be } used for personal business, such as the sale of personal property; } such use must be within the other provisions of this policy. ECC } facilities may not be used on behalf of outside agencies." } }That would allow Joe Shmo to advertise his old Macintosh for sale, but not }(in my mind) announce the current sales at his company, Bluegrass Computing. Looks good to me. }>}Section 3: Electronic Mail Policy }>}3.4 All mailing lists with more than 10 members must be registered with }>} the ECC staff. [Paragraph 1.21u, CSC] }>I'm sorry, this seems absolutely absurd. }My rationale behind this provision comes from several experiences: } } 1) I have had problems with users creating *massive* mailing } lists (over 200 members) with the 'alias' function of mailx. } One of these lists started shipping uuencoded images around. } Chaos ensued. I can certainly understand this one. Maybe its just "10" I didn't like. We have mail-lists for each course (for example: math_123@iastate.edu). Now we create these ourselves, but if we didn't I sure wouldn't want to hear about all of them! } 3) Several students have left this organization without informing } their list members; as a result, I've been getting dozens of } messages from users/postmasters complaining about "user unknown" } email bounces. You'll never shake this one.... :-( }>}It is important to note that the ECC staff will make arrangements for large }>}mailing lists; however, we will not support mailing lists whose subjects }>}violate University policy, State law, or Federal law. }>How could the existence of a mailing list could be illegal? }I know that this particular example has been bounced around for years, but }what about a "child porn image list"? What about a list that passes out }credit card numbers? Well, it seems it is the use which is illegal, not the list. Surely if I was to ask you (as my SysAdmin) to setup such a list I wouldn't ask to call it something like ``WeFondleLittleBoys@ms.uky.edu'', but rather something ordinary sounding like ``wflb@ms.uky.edu''. But then again, maybe these people are really stupid... }UK uses an Ungerman-Bass network, in which each host has a finite number }of ports. When a "popular" system A's ports are all in use, users will }grab a port to another machine B, log in, and telnet to the system they }*really* want to use (system A). This action, in turn, limits the num- }ber of ports to system B that are available for real work. }Very few systems on this campus use hard-wired terminals; the vast majority }(over 90%, in my estimation) of the connections are made through UBNet. The }folks who don't want to wait for access to system A are tying up all the ports }on system B. Right now (and for the past year or so), my systems are acting }as system B; my legitimate users are tired of it, and so am I. Ah! I can see we are very fortunate not to have such a thing. Our serial network is an AT&T ISN (and much as I hate to praise them, it is nice). In any event, serial is fading pretty fast here. Looks like you don't have much choice but to have that rule. }>How do you know if they have even received your instructions (e-mail?). }As far as I'm concerned, the fact that they didn't check their }email doesn't absolve them of responsibility. ... }Your access wouldn't be revoked unless the action(s) continued. I thought }I made that clear. I thought that "Disregarding instructions" implied that }the violations were continuing; I'll reword it in the next draft. }Here's the scenario I envisioned (and the one that has occured several times): } 1) User actions cause problems. } 2) ECC sends email message to user. } 3) Action continues. } 4) Temporary revocation. I was thinking of things which can continue `passively'. Like you created an 11-person mailing list, or whatever. }>}If your access is temporarily revoked, you should immediately contact the }>}ECC Staff for an explanation of the situation. In most cases, the revocation }>}will be lifted within 1 working day. Quite often, temporary revocation is the }>}result of a minor, or apparently unintentional, violation of ECC or University }>}policy; such revocations will be lifted as soon as the ECC Staff discusses the }>}relevant policies with you. }>See above--this is unacceptable. [examples omitted] I still have a real problem with possibly interferring with a student's academic success for `minor, or apparently unintentional, violation[s]'. Certainly if they are a real threat to the system or other users, then immediate action is called for. }>}The ECC will abide by the decision of the Dean of Students. If the Dean of }>}Students chooses not to bring disciplinary action against you, or if the }>}judicial proceedings are resolved in your favor, your complete access to ECC }>}facilities will be immediately restored. }>Access is restricted BEFORE the guilt of the student is determined?!? Same comment as above. ---- Overall, I think you have made a really fine effort; I just like to play the devil's advocate. ;-) Cheers, John
Technical Details
Message-ID:
<1992Apr13.142732.19822@news.iastate.edu>Path:
arc1-ca.pugleaf.net!sparky!uunet!zaphod.mps.ohio-state.edu!uwm.edu!ux1.cso.uiuc.edu!news.iastate.edu!johnReferences:
<1992Apr9.160725.7355@ms.uky.edu> <1992Apr11.150009.6432@news.iastate.edu> <1992Apr13.92643.3006@ms.uky.edu>Show Full Headers
Complete Article Headers
Newsgroups: comp.admin.policy,alt.comp.acad-freedom.talk Path: arc1-ca.pugleaf.net!sparky!uunet!zaphod.mps.ohio-state.edu!uwm.edu!ux1.cso.uiuc.edu!news.iastate.edu!john From: john@iastate.edu (John Hascall) Subject: Re: DRAFT Student Access/Use Policy Message-ID: <1992Apr13.142732.19822@news.iastate.edu> Keywords: opinions welcome....... Sender: news@news.iastate.edu (USENET News System) Organization: Iowa State University, Ames, IA References: <1992Apr9.160725.7355@ms.uky.edu> <1992Apr11.150009.6432@news.iastate.edu> <1992Apr13.92643.3006@ms.uky.edu> Date: Mon, 13 Apr 1992 14:27:32 GMT Lines: 135