There were a bunch of acl's which contained only LIST:sipb-acl  :
sipb-athena-acl               sipb-athena ACL
sipb-minutes-acl              sipb-minutes ACL
sipb-hackers-acl              sipb-hackers ACL
sipb-developers-acl           sipb-developers ACL
gsipb-acl                     gsipb ACL
uus-acl                       uus ACL
usenet-acl                    usenet ACL

I took all the lists owned by these lists and made them owned directly
by sipb-acl.

This is the current list of lists owned by sipb-acl:
sipb-acl                      sipb ACL
        sipb                  Mailing list for SIPB (Student Information Proces                sipb-soc      Social mailing list for SIPB
                sipb-bitnet   Discussion of SIPB support for BITNET communicati        uus                   This is the mailing list for SIPB's /usr/unsuppor        sipb-minutes-acl      sipb-minutes ACL
        charon-maintainers    List for maintainers of charon
        sipb-athena           SIPB's redist of the "athena" list
        gsipb                 charon sipb group
                sipb6035      Subset of a Course List
                sipb6033      none
                sipb6004      SIPB 6.004 mailing list
                sipb6823      none
                sipb6111      SIPB members taking 6.111 (Fall '88)
        sipb-minutes          sipb-minutes
        bug-sipb              problems/questions with /usr/sipb
        usenet                usenet
        sipb-developers       SIPB distribution of developer's list
        sipb-afsreq-acl       Spare list
        sipb-hackers          SIPB distribution of hacker's list
        sipb-bugs             problems/questions with /usr/sipb
        sipb-afsreq           AFS requests for sipb.mit.edu cell

	Is there a distinction anymore between sipb and gsipb?  If not,
	is there a reason not to combine the lists into one?  Is there a
	reason to keep uus, sipb-grad-archive, and sipb-bugs?
	hackers@athena is public.  does sipb need it's own piece?
	sipb-{developers,athena} should probably be owned by sipb, not
	sipb-acl

There are too many lists dealing with sipb sources:

gsipbsrc-acl
        gsipbsrc              SIPB Sources
sipbbin-acl
        sipbbin               SIPB mailing list for people in gsipbbin
gsipbbin-acl                  gsipbbin ACL
        gsipbbin              SIPB Distribution Binaries

	I suggest making one list (gsipbbin, since that's in most
	common use now) be a group and maillist, and add people
	to that.

Random historical lists:

sipb-core-staff-acl
        sipb-core-staff       SIPB staff
sstaff-acl
        sstaff                charon sstaff group
                gcharon       SIPB-sponsored charon accounts
sipb-staff-acl                sipb-staff ACL
        sipb-staff            SIPB people actively involved in stuff

	Someone who knows more than I about these lists should tell
	me what they're for, so they can be combined/deleted if
	necessary.  On srz's advice, I made one "charon-maintainers"
	containing the charon stuff.  sipb-staff has gotten to be used
	as "people who do stuff for the sipb and need generic bits"
	so I'm leaving that for now.  

web
        sipb-iap              none

	chee should make this owned by sipb

beacon-maintainers-acl        ACL for bloom-beacon maint
        beacon-maintainers    bloom-beacon maintainers
sipb-afsreq-acl               ACL for sipb-afsreq
        sipb-afsreq           AFS requests for sipb.mit.edu cell

Both of these lists need to exist, I'm sure.  But, do they need their
own, specific acls?  having them owned by sipb-acl should be sufficient.

sipb-ec                       SIPB ExecComm
	This list should be and is self-administering

sipb-ec should be on sipb-acl.  sipb-acl should be somewhere in the
recursive acl of any sipb group.  Two things: Is sipb-acl too big?  is
it possible that we might want to add additional layers?


MAJOR CHANGES:

sipb-grad-archive is gone.  It's now charon-maintainers.  It contains
the people who were on sstaff or sipbstaff.

More comments 2/17/92:

hmm.  then take, say, beacon-maintainers.  Should I create a
beacon-maintainers-acl which contains only beacon-maintainers and
sipb-acl, and is owned by sipb-acl?  then beacon-maintainers is
self-administrating, and sipb-acl administrated, but sipb-acl doesn't
have to be on beacon-maintainers.  Does this seem like the right model
to you?