\documentstyle[12pt]{article}

\title{Submission of \\
Zephyr Notificiation Service}
\author{Ken Raeburn\\
MIT Project Athena}

\begin{document}

\maketitle

This documentation describes the current version of the Zephyr
Notificiation Service.\footnote{
Project Athena, Athena, Hesiod, Kerberos, and Zephyr are trademarks of
the Massachusetts Institute of Technology (MIT).  No commercial use of
these trademarks may be made without prior written permission of MIT.
}
A revised version is in the design stage, and will be our actual
submission.  Where the new version is expected to differ from the
current one, comments to that effect have been made, describing how it
will differ.

Accompanying this document is the Zephyr Programmer's Manual, the
UNIX$^{\rm TM}$ manual pages for the user programs, and various
technical papers describing Zephyr.

These are our responses to each applicable requirement in the
distributed document dated 15 October, 1990.  The ``key evaluation
criteria'' are addressed within appropriate sections of this document,
or in the accompanying documentation.

The definitions I am assuming in this response are:
\begin{itemize}
\item {\bf event:} Transmission of a notice, or
a change to an object: A network entity (user agent) is created or
destroyed, or subscribes or unsubscribes to a particular type of
notification.
\item {\bf object:} A network entity (user agent or service) that sends or
receives notices.
\item {\bf object class:} Generally not applicable.
\item {\bf object instance:} Same as object.
\end{itemize}

\section{Engineering Requirements}

\subsection{Documentation}

All documentation is in English.  Library documentation describes all
possible error codes; program documentation describes most error
messages that are not self-explanatory.
The less self-explanatory messages (that are currently poorly
documented) generally result from various forms of access denial,
specific reasons for which cannot be described in the current protocol
used; this should be improved (as should the documentation) with the
next version.

No detailed user's guide is available beyond the manual pages.

\subsection{Licensing}

This software is distributed under the following terms:

{\it
All rights reserved.

Permission to use, copy, modify, and distribute this software and its
documentation for any purpose and without fee is hereby granted,
provided that the above copyright notice appear in all copies and that
both that copyright notice and this permission notice appear in
supporting documentation, and that the name of the Massachusetts
Institute of Technology (M.I.T.) not be used in advertising or publicity
pertaining to distribution of the software without specific, written
prior permission.

M.I.T. disclaims all warranties with regard to this software, including
all implied warranties of merchantability and fitness, in no event shall
M.I.T. be liable for any special, indirect or consequential damages or
any damages whatsoever resulting from loss of use, data or profits,
whether in an action of contract, negligence or other tortious action,
arising out of or in connection with the use or performance of this
software.
}

This covers source, object, and documentation.

\subsection{Portability}

The current implementation assumes 4.3BSD sockets and IP network
services (UDP and TCP), and use of the Kerberos authentication system
is desired.

Further dependence on hardware architecture is minimal, and generally
in nonessential areas.  No kernel changes are needed.

\subsection{Standards Compliance}

Most of the source code is written in ANSI C, or will soon be
converted to it.  One program (the central server) is written in C++.

This software has not been examined for compatibility with POSIX or
X/Open standards.

\subsection{Testing}

The current version has no test suite, nor any specific plan for
testing.  This may be addressed during development of the new version.

\section{Software Requirements}

\subsection{Conformity to standardized services and protocols}

We will be looking at the use of ASN.1 for the notice encoding in the
new version, but have not yet decided on the specific representation.

I am not familiar with most of the OSI standards mentioned, so can
give no reasonable evaluation.

\subsection{Conformity to OSF offerings}

Although no proprietary code is involved, many components (such as X
display handling in end-user applications) were written without the
use of OSF-specific code, because of unreliability at the time of
development, unavailability, or performance issues.

The current version in use at MIT makes use of the Hesiod name
service, the Kerberos authentication service (version 4), and BSD
sockets.  The first two are not required, and the latter should be
easily replacible in the next version.

\subsection{National Language Support}

Parameterized messages have been a component of the design from the
beginning.  The other requirements in this section have not yet been
addressed.

\subsection{Interoperability}

Although message transmission between administrative realms is not
possible in the current version, it will be supported by the one under
design.

No effort has been made at this point to use Zephyr from IBM PC-class
machines; however, MacOS versions are under development at the present
time.

\subsection{Heterogeneity}

Currently, Zephyr is in use under BSD on Vax and IBM RT/PC
workstations, under Ultrix on DECstation workstations, under A/UX on
Macintoshes, and (at other sites) on various Sun platforms.  Work is
in progress to provide MacOS client programs, although most of the
library kernel already works there unmodified.

High-speed, moderately reliable TCP and UDP network services are
assumed, though other network protocols will be better supported in
the new version, where the RPC mechanism will be more separated from
the rest of the system.

\subsection{Modularity}

Adaption of various programs to use Zephyr for notifications should
not be difficult; we have done so with many programs here at Project
Athena.

\subsection{Reliability \& Availability}

Our new design will provide for a reliable notificiation subscription
database despite Zephyr server crashes.  (The current implementation
has known design flaws, and a couple of implementation bugs.)

\subsection{Robustness}

Standalone capability: As with server crashes, there are known design
and implementation problems with the current implementation in
handling network partitions that should be fixed for our final
submission.

\subsection{Configurability}

Currently, the server can produce a list of all registered recipients
and their subscriptions.  There is no way to get a list of potential
transmitters.

\subsection{Extensibility}

Addition or removal of clients can be done without modification to the
running service.  New subscriptions are simply added to the current
database.

\subsection{Scalability}

The current implementation handles well an administrative realm of
1000 workstations, using two servers.  There are several scalability
problems, including database synchronization, which will be addressed
with the server redesign, and the new protocol will handle cross-realm
communications.

The existence of the highly dynamic database of notice type
subscriptions, which must be maintained on each (or across many)
servers, makes it seem unreasonable to extend the size of a single
administrative realm higher by more than an order of magnitude or so.

\subsection{Usability}

The Zephyr server is centrally administered.  (Other management tools,
such as those controlling the access control lists governing transmit
access for various types of notices, may permit subset administration,
but it is not a function of the notification system.)  Individual
objects are managed by users, or as aspects of other services.

\subsection{Security of Management}

Zephyr provides for authentication (when Kerberos is used) and
authorization checks for notice transmission and subscription.

\section{Service Specific Requirements}

\subsection{Management Framework}

Terminal- and X-oriented programs are available for receipt and
transmission of messages.  Messages can be redirected to files on
reception.  No mechanism is available currently for saving messages
displayed on a terminal to a file without the recipient making
provisions for it beforehand.

ANSI C
programming interfaces are available to all aspects of the
notification service, except:
\begin{itemize}
\item Details of server control:  Modifications to the access control
lists and server restarts and shutdowns must be done manually (or via
shell scripts or such run by some other management tool), in the
current implementation.  We have no specific plans on this point for
the new version.
\item Formatting of human-readable text in notices:  This is handled
within a client program.
\end{itemize}
The library interface allows access at several abstraction layers,
depending on the amount of control the application desires.

I have not looked at the ``DCE \ldots object naming formats,'' and
therefore have no idea how applicable they are or how difficult it
would be to adapt the user interface and library provided with Zephyr.

Use of Zephyr service is completely independent of an entity's
location on the network.

Zephyr supports all Mandatory and Desired requirements under ``Core
services/Event services and event management'' except for logging and
filtering.  While no facility is provided for a special logging
service, a recipient program can be easily configured to write all
received notifications to a file, or to pass them to other programs.
Filtering can be done in a semi-programmatic way by adjusting
appropriate configuration files, but not in quite the same way that is
mentioned in the requirements.  No flow control is provided.

\subsection{Managed Objects}

None of the objects in Zephyr (user agents and services) are managed
centrally by Zephyr software, except in that the subscription database
is stored centrally on a server that implements access controls.
End-user programs are controlled by the user; special types of
notifications are used to deliver requests to the subscription or
location built-in services.

The only resources used by objects other than system memory, CPU
cycles, and network ports are network bandwidth and server database
space.  No facility is provided for tracking or controlling these
uses.

Most of the other requirements listed in this section appear to apply
only to more general management subsystems; I don't see how to apply
them to notification systems.

\section{Management Applications}

The Zephyr Notification System does not fall into any of the
categories in this section.

\end{document}