🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.admin.policy
Article #46

Re: DRAFT Student Access/Use Policy

#46
From: John Hascall
Date: Mon, 13 Apr 1992 14:27
135 lines
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!john
References: <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