From: Mike Barker <mbarker@MIT.EDU>
To: mbarker@MIT.EDU, sao@MIT.EDU
Subject: LERT Limits and Uses
Date: Wed, 06 Mar 1996 14:33:40 EST

What is Lert?

It is a system developed to deliver deactivition notices to Athena
users being removed.

What does it do?

1.  An administrator loads a list of specific user names into a database.

A very minimal set of tools for administering the db were provided.
They require the administrator to telnet to the specific server and
run them.  Specifically included:

	add a group of users with a single category name (letters)
        remove a user from the db
        remove a category from the db
        list the contents of the db

2.  When the user logs in, lert checks to see if they are in the database.
If they are, it shows them the standard notification for the categories they
are in.

3.  A user can ask lert to remove them from the database.  They will be shown
any pending notification(s) and removed.

4.  All exchanges are protected by kerberos.  The notification files are
protected by AFS acl's.

Limitations?

1.  Lert only provides 26 "categories".  This means it cannot be used
for more than 26 different messages at any time.

2.  Lert does not know anything about the user names.  A complete list
of users for any notification must be provided through some other
means.  E.g., lert has no way of determining who is in a class.

3.  Lert is not mandatory or time-sensitive.  If people do not login,
have customized logins, or even if they simply ignore the message,
there is nothing lert can do about it.  Deactivation messages by their
nature are expected to be mostly ignored.

4.  "Spoofing" lert notification is fairly simple.  Since most people
do not pay attention to the details of the message, a message sent by
zephyr at the correct time (login) and in nearly the right format will
probably be considered a lert notification.  While a user can verify
simply by running lert by hand, I doubt if many think of this.  In the
case of deactivation notices, it isn't too significant if someone
spoofs us.  If lert is going to be used for more kinds of
notifications, we may need to rethink this danger.

5.  Backup/recovery--right now there is only one lert server provided.
I don't think I implemented any fallback (e.g. if the server is down,
try another one) Again, for deactivation notices this seemed
appropriate, but if we are going to broaden the service, we may need
to reconsider the issue.

Necessary Enhancements:

1.  Currently the administrator is expected to telnet to the server
and use "local" tools to add people to the database, remove them, etc.
If there is expected to be more widespread use, the administrator
tools should be "remoted" (converted to client/server).

2.  Increasing the number of categories.  There are presently only 26
available categories.  The protocol for requesting a string from the
server should be modified to allow various queries (a category name
and user name, probably) with a larger number of possible replies.  A
fairly simple extension would be to permit replies in the space
0000-9999 (10,000 groups!)

3.  "Tailoring" replies.  Currently lert does nothing except display
(via zephyr, cat, or email) the standard message.  A fairly simple
extension (like 2) would allow the client to send a username and string,
then get back a string--which would then be used in rewriting the standard
message.  e.g.  if the message had <>grade<> in it, send the server the
string "grade" and the user id, then take what it returns and put that in
place of <>grade<>  This kind of dynamic message content would be useful
(although for grades, simply dividing the group into several subgroups and
using separate messages for each one would also work).

Alternatives:

1.  A modified discuss client could be used to collect new messages
for the user based on some kind of profile from various discuss-style
lists.  For example, if the profile says to get classof2001 messages,
it would collect any new messages from that list.  If the profile
includes "major6", it would collect messages for that major.

Benefits: the discuss model is well-understood and supported.  All
that is needed is creation of the appropriate lists on an appropriate
server plus publicity to let the users know they should be reading
certain lists.  A modified set of clients can make this even easier,
but most of the benefits can be gotten without even doing that.