🚀 go-pugleaf

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.
>
>}                                          ... No disciplinary action will be
>}taken against students by the Engineering Computing Center; if such action
>}is contemplated, the matter will be remanded to the appropriate office.
>             [this appears to not be true, see below]

Hmmmm....I'll change "disciplinary action" to "PERMANENT disciplinary action".

>}1.1   Use of restricted ECC facilities by those students outside the College
>}      of Engineering is prohibited.  [Paragraph 1.21u, CSC] 
>
>What about students not in the Engineering College but who are taking
>an Engineering Course?  Where do they fall?

We usually handle this through the instructor; they give me a class roll, and
I crank up the guest accounts.  I'll formalize a procedure and put it in the
next draft.

>}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?

>Some assurance that these policies and/or instructions will also be in
>accordance with, and not superior to, University policy?
>
>An assurance that files/data `accidentally' seen will be not be divulged?

You got it; suitable assurances will be in the next draft.

>}2.2   Attempts to evade or change resource quotas are prohibited.
>}      [Paragraphs 1.21a, 1.21h, and 1.21u, CSC]
>
>I assume you *are* allowed to change a quota by requesting a change from ECC?

Yup; I'll put a formal procedure in the next draft.

>}2.3   Continued impedance of other users through mass consumption of
>}      system resources, after receipt of a request to cease such activity, is
>}      prohibited.  [Paragraph 1.21a, CSC]
>
>How does someone who feels his consumption of resourses is warranted
>(necessary to their academic success) seek appeal?

Hmmmm......I guess I'll put a "Complaint/Appeal Policy" in the next draft.

>}2.4   Use of ECC facilities and/or services for commercial purposes is
>}      prohibited.  [Paragraphs 1.21g and 1.21u, CSC]
>
>Definition of `for-profit'?  Is, for example, using misc.forsale allowed
>or not allowed.

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.
	 
>}ECC resources are dedicated to academic work.  At this time, we cannot
>}support game or recreational programs.  Therefore:
>}
>}2.5   The installation/execution of games and/or recreational programs on 
>}      ECC systems is prohibited. [Paragraph 1.21u, CSC]
>
>Definition of recreational?  News?  Only certain newsgroups?  E-mail?
>Talk?  IRC?  Playing MUD?  Writing MUD?  Writing a program not required
>in any class?  Fortune?  FTP?  Archie?  ...

True; I think the reference to "recreational" will be removed.  The
provision prohibiting "network-based applications" will eliminate
MUD/IRC/Netrek/etc. programs, so this provision can be safely rewritten.

>}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.
	   
	2) Users have also created mailing lists of people they don't
	   even know, in the hopes of meeting 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.

	4) Two users tried to import the entire UK "email phone book" into
	   a mailing list.  There are over 6000 addresses in the "phone book";
	   with the transcription errors that were made, it took me over two
	   weeks to fix the errors, track it down and kill it.

>}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.  (In any situation where
>}this is a possibility, the University Counsel will be asked for a decision.)
>
>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?

>}There are a limited number of network ports available to certain systems. 
>}It is possible to connect to other systems via ECC systems.  This misuse of
>}ECC systems may result in depriving other users of access to our systems. 
>}We cannot support use of computers outside of the ECC.  Therefore:
>}
>}4.2   Use of ECC systems and/or networks to connect to other systems, in
>}      evasion of the physical limitations of the remote system/network, is
>}      prohibited. [Paragraph 1.21a and 1.21u, CSC]
>
>I don't understand this.  For example, we have a system with 1 serial
>connection.  Is telneting to that system an "evasion of the physical
>limitations"???  Why is that banned???

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.

>How do you know if they have even received your instructions (e-mail?).

Well, a quick check of the sendmail logs will indicate success/failure of
delivery.  As far as I'm concerned, the fact that they didn't check their
email doesn't absolve them of responsibility.  In the "real world", the
Circuit Court doesn't care if you "didn't receive" their summons; they'll
haul you in anyway.  What's the difference?

>If, for example, I was not on the system for a week or so, tried to use
>the system some Saturday to complete a project due Monday morning and
>found I my access revoked because I had not followed instructions (that
>I never received) and my academic success was jepordized I would be furious.

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.

>}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.

What's the alternative?  I had a user who consistently crashed the system
with a shell script that hosed out the ethernet card.  I sent THREE email
messages; he kept running the script.  I tried to telephone him, but his num-
ber wasn't listed.  What the heck am I supposed to do?

>}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?!?

Yup, it sure is.  If I have evidence that a user is using one of the
systems for cracking attempts on other systems, you'd better believe that
I'm going to throw him into a "no network access" restricted shell until
we know more.  (I should point out that NONE of the classes in Engineering
require network access; therefore, this action will not restrict his class-
work) 

If I have evidence that a user is using other user directories as storage
(in violation of resource quotas), you'd better believe that he's going to
find himself in a restricted shell when next he logs in.

-- 
 morgan@ms.uky.edu    |Wes Morgan, not speaking for|     ....!ukma!ukecc!morgan
 morgan@engr.uky.edu  |the University of Kentucky's|   morgan%engr.uky.edu@UKCC
 morgan@ie.pa.uky.edu |Engineering Computing Center| morgan@wuarchive.wustl.edu
        "I was going to rip your head off, but I'm past that now."