Simple Event Notification Service Environment
(SENSE)
Frequently Asked Questions
(FAQ)

Version 0.3

19 January 1996

JK Martin
Underscore, Inc.

Richard Landau
Digital Equipment Corporation

This document presents answers to many of the frequently asked questions about the Simple Event Notification Service Environment (SENSE) initiative currently being researched by the Printer Working Group (PWG) organization.

Comments, suggestions and general discussion surrounding SENSE are currently conducted through the PWG's electronic mailing list (pmi@hpbs987.boi.hp.com). Contact information for the authors may be found at the end of this document.

Historical Overview

SENSE was first proposed by an ad hoc group within the IEEE Transport Independent Printer System Interface (TIPSI) committee in November, 1995, as a potential technique for easily propagating event-oriented network printer status using a low-cost datagram service to network clients. The original ad hoc group consisted of JK Martin (Underscore), Rick Landau (Digital Equipment Corp.) and Mike Timperman (Lexmark).

Since the initial concept appeared to have widespread applicability in the general network printer environment--and since the ad hoc group members were also part of the PWG--the concept was presented to the PWG as a possible group research initiative with the potential for standardization. The concept was quickly embraced by the PWG and more significant research was conducted by the ad hoc working group in late 1995 to develop preliminary specifications for the SENSE model.

Current Status of Research

As of this writing, Underscore is rapidly developing a prototype SENSE Framework in the Unix domain to test performance, integration and usability ideas and issues. It is a goal of Underscore to develop and release a minimally complete SENSE Framework for general distribution for others to explore the potential of simple, event-based management services for network printers and other network devices and entities.

Directory of Questions

Following is a simple directory of the list of frequently asked questions. Each question is presented with its corresponding answer in the next section of this document.

Q1 -- Briefly, exactly what is SENSE?
Q2 -- What are the goals of SENSE?
Q3 -- What is SENSE not supposed to be? (Non-goals)
Q4 -- Why is SENSE needed?
Q5 -- What kinds of people can benefit from SENSE?
Q6 -- How can SENSE assist in the integration of network management tools?
Q7 -- How does SENSE compare with SNMP?
Q8 -- Doesn't SNMP give you the capabilities provided by SENSE?
Q9 -- Is SENSE integrated with other network management products?
Q10 -- What is meant by "relatively reliable datagram service"?
Q11 -- Is SENSE only designed to work with network printers?
Q12 -- Can a network device directly provide SENSE services?
Q13 -- What network support is provided and/or required with SENSE?
Q14 -- On which platforms can SENSE be used?
Q15 -- What is a SENSE session like?
Q16 -- What are the components of a SENSE system?
Q17 -- What is a SENSE Server?
Q18 -- What is a SENSE Client?
Q19 -- What is a Subscription Period and why is it needed?
Q20 -- What happens when a Subscription Period expires?
Q21 -- What is a Publication?
Q22 -- What is an Edition of a Publication?
Q23 -- What is a SENSE Event Message?
Q24 -- What are the kinds of Event Messages defined in SENSE?
Q25 -- What is an Event Protocol?
Q26 -- What Event Protocols are provided with SENSE?
Q27 -- How can a Client discover the locations of SENSE Servers?
Q28 -- Does a SENSE Server offer its services using a fixed transport address?
Q29 -- Can reliable, stream-oriented network transports (such as TCP) be used with SENSE?
Q30 -- Can a potential Subscriber learn which Publications are available on a given SENSE Server?
Q31 -- How is a Publication uniquely identified on a Server?
Q32 -- What are the rules for naming a Publication?
Q33 -- What can a Client learn about a specific Publication?
Q34 -- What is meant by the Publication's "class"?
Q35 -- How are Publication classes defined?
Q36 -- Is the number of Publications bound to a Server fixed over time?
Q37 -- How can a Client learn when a Publication becomes available or goes away on a Server?
Q38 -- Do the Properties for a Publication change over time?
Q39 -- How does a Subscriber determine the state of an entity from a SENSE Event Message?
Q40 -- What is meant by "Condition?"
Q41 -- Isn't "Condition" just another name for "State"?
Q42 -- What are the various Conditions?
Q43 -- What are "persistent" versus "transient" Warning Conditions?
Q44 -- What is the difference between an Operator and a Technician?
Q45 -- Do SENSE Servers know about each other?
Q46 -- Can a SENSE Server be a Client to another SENSE Server?
Q47 -- Does a Publisher know about its Subscribers?
Q48 -- Can a Client discover the list of Subscribers on a SENSE Server?
Q49 -- How can a Client monitor the activity of Subscribers on any given SENSE Server?
Q50 -- Are SENSE Clients authenticated?
Q51 -- What protocols are used in SENSE?
Q52 -- How would you characterize the wire format of the SENSE protocol?
Q53 -- Where can I find out more about SENSE?


These questions are answered in the following section.

Frequently Asked Questions

Q1 -- Briefly, exactly what is SENSE?

SENSE is a mechanism for delivering asynchronous notifications of events in a computer network.

Until recently the focus of SNMP-based management facilities has been within the sole dominion of network management personnel. This focus has been on such network devices as routers, gateways, hubs and similar network products; that is, products whose sole purpose in life is to facilitate distributed computing. As such, the average user on a network was not interested in SNMP-related management tools and activities.

Enter the network-manageable network printer and suddenly we have the potential for turning the world upside down with respect to network activity relating to management of such printers. Suddenly even the most unsophisticated user is interested in (possibly continuously) running a network printer management application that can display such information as printer availability, current levels of activity on a set of printers, and whether a job recently submitted by the user has completed on a particular printer.

SENSE is designed to facilitate such management requirements while significantly reducing the host and network load to accomplish the solution.

Back to TOP

Q2 -- What are the goals of SENSE?

The development of SENSE was motivated by several primary goals:

• Provide reasonably reliable notification of asynchronous events in a network, such as those generated by SNMP and other communication protocols, including both management and non-management protocols
• Provide a standard, vendor-independent mechanism for dynamic registration for and recipt of asynchronous event notices from a collection of entities without having to effect explicit sessions with those entities
• Provide a mechanism that uses resources sparingly and scales well to very large networks
• Provide a simple, lightweight service that can be quickly implemented across many different kinds of client and server platforms
• Permit multiple clients to use this mechanism on a single system without requiring a system-level service to coordinate their activities
• Promote a simple form for the expression of the overall operational status of a managed entity

Back to TOP

Q3 -- What is SENSE not supposed to be? (Non-goals)

SENSE should not be designed to replace any other network protocols such as SNMP or NPAP; instead it should augment these protocols to provide much needed timely receipt of events within these protocol domains.

Primarily, SENSE is NOT designed to effect the management of any given entity; for example, SENSE is not designed to provide the ability to set operational parameters for a network entity.

Back to TOP

Q4 -- Why is SENSE needed?

While SENSE is not specifically and solely targeted at the SNMP universe, it is the many deficiencies in SNMP's TRAP mechanism that make SENSE an attractive augmentation to the management of entities in a distributed environment.

The SNMP protocol is not intended to provide timely and reliable notification of asynchronous events to a dynamic set of interested client systems and applications. SENSE specifically addresses several aspects of these needs.

Additionally, the simple design of SENSE should allow for rapid and widespread integration of existing management mechanisms that do not use SNMP as the basic management protocol.

Each of these aspects is described in more detail in later questions.

Back to TOP

Q5 -- What kinds of people can benefit from SENSE?

System and network management personnel will no doubt benefit the most from SENSE, However, depending on the kinds of SENSE-compatible tools that are delivered to the marketplace, end users, too, should benefit in being able to monitor key events pertaining to their individual environments; for example, knowing when a user's print job has completed when printing in a highly heterogeneous computing environment.

SENSE can also be of use to developers of client-server components and systems who need to respond quickly to asynchronous events. In particular, developers of SNMP agents and SNMP-based management tools should benefit from using SENSE.

Back to TOP

Q6 -- How can SENSE assist in the integration of network management tools?

The SENSE protocol used by an entity to announce the occurrence of an event is quite simple and should be easily incorporated into existing agent software for the entity.

A SENSE Server is capable of presenting a collection of such entities to a SENSE client, thereby making it easier for users to incorporate various diverse tools to present a more comprehensive view of a set of managed entities.

Back to TOP

Q7 -- How does SENSE compare with SNMP?

SENSE provides an additional delivery method that SNMP agents and management stations can use to get timely notices of events in the network. In this way, SENSE can function as a "wrapper protocol" around SNMP and other management protocols.

Back to TOP

Q8 -- Doesn't SNMP give you the capabilities provided by SENSE?

SNMP provides a mechanism for generating TRAP messages that can inform management applications of events. However, there are problems with the standard design of the SNMP TRAP mechanism:

• There is no standard way defined within SNMP for a SNMP agent to dynamically add or remove TRAP recipients during the life of the agent. As a result, implementations for specifying and loading TRAP recipients vary widely from vendor to vendor. Moreover, most implementations do not provide a way for a client to dynamically control receipt of TRAP messages without reconfiguring the SNMP agent.
• TRAP messages are defined to be sent to only a single defined port on a network host; unfortunately, there is no standard mechanism to demultiplex or otherwise broadcast TRAP messages received on this single port to any number of interested parties
• TRAP messages are sent via unreliable datagrams; moreover, only a single transmission of any given TRAP message is attempted by the managed entity, resulting in the chance of the TRAP being lost on the network and never arriving at the prescribed destination(s)

Since TRAP messages are not delivered reliably, management applications must continually poll the SNMP agent to accurately determine whether a problem has arisen within the managed entity, thereby significantly reducing the value of the TRAP message.

Perhaps the worst ramifications of the deficiencies of the SNMP TRAP mechanism is the significantly increased network traffic required to poll managed entities to determine current operational status. As increasing numbers of network-manageable devices come onto the market--together with increasing numbers of management applications suitable for use by unsophisticated users--the network traffic resulting from all the SNMP polling represents a considerable burden on network bandwidth requirements and related resources.

Back to TOP

Q9 -- Is SENSE integrated with other network management products and tools?

As of the time of this writing, January 1996, SENSE is still in the proposal and prototype stages, and therefore is not yet implemented in any products. However, it is expected that prototype tools will become available by the middle of 1996; such tools will include entirely new tools based on SENSE technology, as well as existing tools that have been retrofitted to be compatible with SENSE (sometimes called being "SENSEable").

Back to TOP

Q10 -- What is meant by "relatively reliable datagram service"?

SENSE uses datagram services to effect all communcations with Clients. For IP-based networks, the UDP datagram transport is used; this transport is inherently unreliable, whereby datagrams can get lost on the network without knowledge by either the sender or receiver.

Since timely and reliable receipt of Event Messages by Subscribers is one of the motivating concerns of SENSE, a UDP-based SENSE Server will periodically retransmit an Event Message to a Subscriber until the Server receives an explicit receipt acknowledgement message from the Subscriber for that Event Message.

A SENSE Server will only retransmit an Event Message a configurable maximum number of times, afterwhich the Server discards the Event Message for that particular Subscriber. This is done so as to limit the resources requirements of the Server.

This periodic retransmission technique is described as being "relatively reliable" in all SENSE documentation, as absolute reliability is considered impractical for a typical SENSE implementation.

Back to TOP

Q11 -- Is SENSE only designed to work with network printers?

No, SENSE can be used with nearly any type of network entity, whether it is a device directly attached to the network or simply a process running on a network-attached host. As long as the entity can produce datagrams on a network, then it can participate in the management facilities offered by SENSE.

Back to TOP

Q12 -- Can a network device directly provide SENSE services?

Yes, SENSE services can be provided directly by a network- attached device. It is also possible to develop SENSE applications that operate as proxies for other devices that do produce asynchronous event notices but do not directly provide SENSE services; such a structure is analogous to an SNMP proxy agent.

Back to TOP

Q13 -- What network support is provided and/or required with SENSE?

SENSE does not itself provide any support for network protocols; it is intended to be layered on the network transport capabilities of its operating system platform. SENSE requires only a datagram-level protocol to communicate between clients and servers.

Back to TOP

Q14 -- On which platforms can SENSE be used?

SENSE is designed to be virtually platform-independent in its implementation and, hence, should be available to all common computing platforms found in today's network environments.

The initial implementations of SENSE clients and servers are expected to be available on Sun Solaris, Digital Unix, Silicon Graphics IRIX, SCO ODT and Windows NT; SENSE clients should also be available for Windows 3.1 and Windows '95. SENSE should be easily ported to any other platforms that have either streams-based or socket-based network interfaces.

Back to TOP

Q15 -- What is a SENSE session like?

An overview of a common scenario might be appear as follows:

• A SENSE server starts up; this may be done at system boot time, but not necessarily.
• One or more SENSE "Publishers" register their defined "Publications" (potential sources of events) with the Server.
• A Client application requests a list of all known Publications from the Server.
• The Client requests of the Server to be registered as a "Subscriber"; the registration mechanism requires the negotiation of a "Subscription Period" of finite length.
• The Client subscribes to Publications of interest.
• A Publisher sends the Server an Event Notice.
• The Server packages the Event Notice and sends copies to all registered Subscribers.
• The Subscriber receives the Event Notice, then sends an acknowledgement to the Server.
• If the Server does not receive an acknowledgment from the Subscriber, it resends the Event Notice; this continues until either some maximum number of retries is reached, or until a retry period is exceeded.
• The Subscriber renews the Subscription with the Server as necessarily, usually when the Subscription Period is about to expire.
• When the Subscriber is no longer interested in receiving events from the Publication, the Subscriber may cancel the Subscription.
• If a Subscription Period expires, the Server automatically unregisters the Subscriber without further intervention by the Subscriber.
  
  Back to TOP
  
  Q16 -- What are the components of a SENSE system?
  
  A SENSE system consists of a Server, one or more Subscribers, and one or more Publishers; each Publisher may publish one or more Publications, where a Publication represents a single source of events that might be of interest to one or more Subscribers.
  
  Back to TOP
  
  Q17 -- What is a SENSE Server?
  
  A SENSE Server is an application program that mediates between Publishers of event notices and Subscribers who wish to receive those event notices. A Server can be implemented as an application (or group of applications) on a network host, or may be implemented entirely within an embedded network device, much like a typical SNMP agent.
  
  Back to TOP
  
  Q18 -- What is a SENSE Client?
  
  A SENSE Client is any entity that communicates with a SENSE Server. There are four distinct types of Clients:

  Subscriber	A Client that formally registers with the Server, typically for the purpose of subscribing to one or more Publications available on the Server.
  Publisher	A Client that formally registers with the Server in order to register one or more Publications. A Publisher may be any network-aware entity, for example, an application on a network host, a component of an operating system, or a network device.
  Manager	A Client that formally registers with the Server to perform certain management functions on the Server. This type of Client is not currently described within this document.
  Transient	A Client that does not formally register with the Server, but otherwise makes certain queries of the Server to obtain information about available Publications and certain Server operating parameters. A Client can not receive events until it properly registers as a Subscriber and subscribes to one or more available Publications. Clients communicate with a Server using the "CommonSENSE" protocol.

  
  Back to TOP
  
  Q19 -- What is a Subscription Period and why is it needed?
  
  A Subscription Period is a period of time negotiated between a Subscriber and a Server during which time the Server will attempt to send copies of all events from all Publications for which the Subscriber has subscribed.
  
  The reason for having a defined period of time between the Subscriber and the Server is to help limit the resources required by the Server to support large numbers of Subscribers over long periods of time when the underlying network transport is an unreliable service. That is, without a reliable transport service, the Server is not able to know when a Subscriber has gone away; as a result, the Server must be allowed to recover the resources used by a Subscriber that no longer communicates with the Server.
  
  A Subscription Period is "negotiated" between a Client and a Server using the following procedure:
  • The Client sends a RegisterSubscriber message to the Server; contained within the message is the time period the Client proposes as a Subscription Period.
  • If the Server accepts the new Subscriber, it returns the Subscription Period in the acknowledgement message to the Client.
  • The Client then uses the Server-assigned Subscription Period in order to send any potential Renewal messages should the Client live beyond the Subscription Period and desires to continue its Subscription with the Server.
  
  
  Only registered Subscribers will have Subscriptions outstanding at any time; the number of such Subscribers is a small fraction of those Clients who would be generally interested, or who have been interested recently. That is, SENSE is designed so that a Server does not have to be able to know about and service all Clients that may exist within the network environment at any given time.
  
  Back to TOP
  
  Q20 -- What happens when a Subscription Period expires?
  
  When a Subscription Period expires, the Server deletes the Subscriber from its registry. It is the Client's responsibility to keep its registration active with the Server as long as the Client is interested in event notices for which it has subscribed.
  
  A SENSE Server is also able to send out a "Renewal Reminder" message to Subscriber when a particular Subscription is about to expire. The reminder message is only sent a couple of times to the Subscriber (until a Renewal message is received from the Subscriber), and this message does not have to be acknowledged by the Subscriber.
  
  The "Renewal Reminder" message is provided for very simple Subscriber implementations that may not have access (or easy access) to timer facilities.
  
  Back to TOP
  
  Q21 -- What is a Publication?
  
  A Publication is a metaphor within SENSE to denote a single source of events that may be of interest to a Subscriber.
  
  A Publication is "owned" by a Publisher currently registered on a SENSE Server. The Publisher is totally responsible for the contents of a Publication; the Server merely facilitates access to the Publication by Subscribers, and attempts to ensure that all Subscribers receive event notices from the Publication in a timely and reasonably reliable manner.
  
  Each Publication has indentifying attributes (called "Properties") that may be queried and examined by Clients. The most important aspect of a Publication, however, is the kinds of event notices that the Publication may issue.
  
  The most important aspect of a Publication event notice is the event data contained within the notice. This data can be of any form defined by the Publisher, and all Subscribers must know how to interpret this data in order to resolve the appropriate semantics of the event.
  
  Just as in human languages, there are many different ways a computer-based entity may convey semantic information. For example, if the entity encounters a particular fault, it can express that fault event in virtually limitless ways, bounded only by the imagination of its developers (and the position of its marketing organization... ;).
  
  In order to support as many different kinds of Clients as possible, a Publisher may provide a Publication in one or more "Editions" for which a Subscriber may subscribe.
  
  Back to TOP
  
  Q22 -- What is an Edition of a Publication?
  
  A Publication may have many different forms targeted for different kinds of Subscribers. Each of these forms is called an "Edition" of the Publication.
  
  An Edition may vary by different dimensions, including:
  

  Syntax (Form)	The precise encoding of the event data; examples might include: SNMP TRAP, SNMP GetResponse, SNMP varbind list, TIPSI alert, CPAP alert, or any other format provided by the associated Publisher.
  Content	The scope of the data represented by the Publication; for example, a particular Edition may be designed to only issue events pertaining to a particular subsystem of the represented entity, while other Editions of the same Publication might cover other (potentially overlapping) subsystems. In many respects, this dimension is analogous to the use of SNMP community name strings that map to certain subsets of the overall data managed by a specific SNMP agent.
  Periodicity	How often the event data is issued; an Edition could be defined so as to issue certain kinds of information only within a defined interval.

  
  An Edition can be arbitrarily defined by the Publisher to be any combination of these dimensions. A potential Subscriber can learn of the Editions available for any given Publication through queries to the Server; after receiving the response to such a query, the Subscriber may then interpret the information to determine whether it can interpret events for that Edition.
  
  Of the various dimensions described above, the most important is the Syntax, or Form of the message, as this aspect represents one of the most powerful abilities of SENSE to provide a relatively universal "glue" in bringing together management tools across various platforms and vendors.
  
  For any given Publication, one of the available Editions is defined as being the "default" Edition; when a Subscriber subscribes to the Publication, but does not specify a particular Edition, then the default Edition will be used.
  
  The concept of Editions may be confusing to some readers. It is expected that a document will be published in the near future describing various scenarios for ways in which a Publisher might want to publish a Publication with multiple Editions.
  
  Back to TOP
  
  Q23 -- What is a SENSE Event Message?
  
  When a Publisher sends the Server an event notice for a particular Publication, the Server encapsulates the event data contained within the notice into an Event Message. Copies of this Event Message are then sent to all Subscribers of the Publication.
  
  The Server takes the Publisher's event notice and places it inside an Event Message; the event notice information can be of any form that the Publisher chooses, based on registration information provided by the Publisher when it registers the Publication with the Server.
  
  The Server does not alter the content of the Publisher's event notice in any way; the event data is placed inside the Event Message, along with certain indentification data such as a timestamp, optional Publisher-provided tag information, and the Subscription Id known to the receiving Subscriber.
  
  Back to TOP
  
  Q24 -- What are the kinds of Event Messages defined in SENSE?
  
  Currently there are three classes of Event Messages defined within SENSE:
  

  Condition	Declares the current operational status of the Publication using standard, SENSE-wide values. Essentially this information states the overall "health" of the entity represented by the Publication.
  State	Describes a particular kind of change in state; such information is highly specific to the Publication, and the Subscriber is expected to fully understand both the syntax and semantics contained within the event data of the Event Message.
  Info	Any information of a general nature that has become available within the Publication. Again, the syntax and semantics of the event data are highly specific to the Publication.

  Back to TOP
  
  Q25 -- What is an Event Protocol?
  
  An Event Protocol is the name given to the syntax and related semantics for the event data issued by a Publication. Examples might be "SNMP.Trap" or "TIPSI.Device.Alert".
  
  Back to TOP
  
  Q26 -- What Event Protocols are provided with SENSE?
  
  The only standard Event Protocol provided by SENSE is the "CommonSENSE" protocol. This protocol is used to describe events within the SENSE Server itself, such as the registration or unregistration of a Subscriber, Publisher, Publication, or Edition; or when certain operational conditions exist, such as the maximum number of supported Subscribers has been reached, etc.
  
  All other Event Protocols are defined by the Publishers of those Publications; for example, an SNMP Agent, as a SENSE Publisher, defines the Event Protocol of its Publication and any potential Editions of that Publication.
  
  The CommonSENSE protocol is designed to be readily usable by many different kinds of potential Publishers. The syntax of the protocol allows for a reasonably rich set of semantics for a large number of entities.
  
  The CommonSENSE protocol is presented as part of SENSE as a means of fostering rapid deployment of Publishers by vendors and customers who do not wish to get deeply involved in designing and implementing their own Event Protocols for use with SENSE.
  
  Back to TOP
  
  Q27 -- How can a Client discover the locations of SENSE Servers?
  
  The SENSE server operates by default on a well-known port within the network being used. In IP, IPX, and AppleTalk networks, these port numbers will be registered and published using the appropriate mechanisms and procedures.
  
  When SENSE Servers use this default transport address, Clients should be able to locate the Servers using techniques similar to that used in the SNMP community; for example, broadcast one of the valid query messages to the default SENSE datagram port on all hosts on a given network, or some defined subset of hosts.
  
  To facilitate this activity--as well as provide a general communications connectivity test--SENSE provides a simple "Loopback" message that functions similarly to the standard Internet "echo" protocol to effect a "ping" of a target Server or collection of Servers.
  
  Back to TOP
  
  Q28 -- Does a SENSE Server offer its services using a fixed transport address?
  
  While a default SENSE service port is defined on various types of networks, a Server should be able to operate on any datagram transport address specified by the managing organization.
  
  It is a primary goal to allow the capabilities provided by SENSE to be employed by persons not directly responsible for management of the host on which the Server operates. That is, the Server does not necessarily require the use of a "privileged port" to fully operate. This approach has the advantage of allowing any organization to provide event services for any type of entity to any number of Clients on the network, making the organization responsible for Server operations.
  
  A particular SENSE Server implementation may be capable of offering its services on multiple ports, based on the needs of its targeted Clients, whether Subscriber or Publisher. Historical or management requirements may dictate that certain Publishers expect a certain non-default transport address, while Subscribers may expect services on the default standard port. Server implementations should are not precluded from servicing multiple ports at any given time.
  
  In the case where conflict arises in the assignment of port addresses, SENSE Servers and Clients must be able to adapt to custom network configurations. Server and Client implementations should provide options for specifying other than the default transport address.
  
  Back to TOP
  
  Q29 -- Can reliable, stream-oriented network transports (such as TCP) be used with SENSE?
  
  Yes, it is possible to implement SENSE Servers and Clients that communicate using connection-oriented transport protocols such as TCP or SPX. Some implementations of some transport protocols include "heartbeat" or "keep-alive" messages that periodically validate the connection.
  
  For some situations it might be desirable or required for a SENSE Server to provide services over such reliable stream transports to increase the reliability of transmissions of events, or to more rapidly detect the unexpected absence of Subscribers and/or Publishers.
  
  Back to TOP
  
  Q30 -- Can a potential Subscriber learn which Publications are available on a given SENSE Server?
  
  Yes, a Client can request a list of Publications available on a SENSE Server using query messages defined in the SENSE Client Protocol.
  
  Back to TOP
  
  Q31 -- How is a Publication uniquely identified on a Server?
  
  A Publication is registered on a Server under a name assigned by the manufacturer of the Publisher, which is typically a device or software agent.
  
  Back to TOP
  
  Q32 -- What are the rules for naming a Publication?
  
  The names of Publications are strings assigned by the manufacturers of the Publishers. It is suggested that names be structured hierarchically: manufacturer, Publisher within manufacturer, Publication within Publisher, etc.
  
  Note that as of this writing, no naming authority or similar registrar has been identified; this situation remains to be resolved before the deployment of SENSE.
  
  Back to TOP
  
  Q33 -- What can a Client learn about a specific Publication?
  
  The protocol and registration process allow for great latitude by a Publisher is defining the "Properties" of a Publication or its related Editions.
  
  Currently the standard set of Publication Properties include the following set; note that words in parentheses indicate the name of a standard MIB-II System Group object with synonomous semantics and syntax:

  Name	Administrative "friendly" name
  Hostname	Network host name or address
  Class	Defined class of the Publication
  Description	General description (sysDesc)
  Location	Location of the entity (sysLocation)
  Contact	Personnel contact info (sysContact)
  Objectid	ASN.1 OID (sysObjectId)
  EditionList	Name list of available Editions
  Version	Version info for this Publication
  Condition	The last known condition of the entity
  PublishDate	Date/time when Publication started
  Vendor	Vendor identification
  Model	Model identification
  Package	Product packaging identification
  URL	Universal Resource Locator spec
  PublisherId	The Server-assigned ID of the Publisher

  
  These are the standard Properties for a Publication. The protocol used within SENSE allows for the arbitrary inclusion of any number of named Properties that are stored by the Server when a Publisher registers a Publication; when a Client retrieves the Properties of a Publication, these extra Properties are included in the response and made available for the Client's use.
  
  It is interesting to note that this approach in managing Properties extends to Subscribers, Publishers and Editions, making SENSE one of the more extensible information "clearinghouses" available on the network.
  
  Back to TOP
  
  Q34 -- What is meant by the Publication's "class"?
  
  A Publication's class is a structured text string identifying the type of entity being represented by the Publication. In SNMP and other ASN.1 environments, the class is a type of OID used to distinguish specific type information.
  
  Back to TOP
  
  Q35 -- How are Publication classes defined?
  
  The registration of class names has yet to be determined and currently remains a research and development issue.
  
  In the interests of promoting and quickly deploying SENSE technology, Underscore, Inc., is willing to serve as a temporary registrar for this and other name registration requirements within SENSE until such time as a more suitable registrar can be employed.
  
  Back to TOP
  
  Q36 -- Is the number of Publications bound to a Server fixed over time? That is, do Publications come and go for any given Server?
  
  The number of Publications on any given Server is not necessarily constant (fixed). Publications can be registered and unregistered during the life of a Server.
  
  In particular, when a Server first starts up, there may be no Publications registered; in this case, the Server will expect one or more Publishers to eventually register themselves, followed by the registration of one or more Publications.
  
  Back to TOP
  
  Q37 -- How can a Client learn when a Publication becomes available or goes away on a Server?
  
  Registering and unregistering of Publications are significant events in the SENSE Server. These events generate Event Notices in the CommonSENSE protocol. Clients may subscribe to those events and be notified immediately of the creation or deletion of Publications.
  
  Most clients will be interested in only a few Publications. They may have to subscribe to Publication registration events only until the desired Publications are registered in the Server. However, large network management applications may always be interested in new sources of events as they become available, and hence, wish to monitor the registration of Publications on a permanent basis.
  
  Back to TOP
  
  Q38 -- Do the Properties for a Publication change over time?
  
  Yes. A Publisher is able to change the current Properties for one of its Publications at any time. When this happens, the Server will issue (as one of its defined Events) a "PublicationUpdated" Event; if a Subscriber has subscribed to the Server's own Publication (that issues Server-wide and Server-related Events), then the Subscriber will be able to detect such changes in a particular Publication's Properties.
  
  Back to TOP
  
  Q39 -- How does a Subscriber determine the state of an entity from a SENSE Event Message?
  
  If the Event Message is a "Condition" message, then the Subscriber should be able to easily extract the associated Condition code from the message.
  
  For other types of Event Messages, the Subscriber must be able to parse the specific format and derive the semantics of the event data contained in the Event Message.
  
  Back to TOP
  
  Q40 -- What is meant by "Condition?"
  
  The "Condition" of a Publication represents the overall "health" indication for the entity represented by the Publication.
  
  A primary goal of SENSE is to provide a virtually universal expression for the overall (summary) operational state of a managed entity to facilitate monitoring by differing types of Clients.
  
  Back to TOP
  
  Q41 -- Isn't "Condition" just another name for "State"?
  
  The term "Condition" was arbitrarily chosen due to the multi-faceted nature of the term "State". A simple, concise term was needed that represented the overall, summary "health indicator" of the managed entity.
  
  Back to TOP
  
  Q42 -- What are the various Conditions?
  
  The following enumerated values (names) are defined as Conditions:
  

  Unknown	Current condition not available
  Healthy_idle	No problems, no work being done
  Healthy_busy	No problems, busy working
  Warning_transient	Warning, but for a short time
  Warning_persistent	Warning, will not go away
  Alert_operator	Problem, requires an Operator
  Alert_technician	Problem, requires a Technician

  
  These values may not satisfy the requirements of all entities, but should suffice for the vast majority.
  
  Back to TOP
  
  Q43 -- What are "persistent" versus "transient" Warning Conditions?
  
  A persistent Warning would be one that will not go away without human intervention. Using printers as an example type of managed entity, a "persistent" warning would be something like "toner low", "paper low", etc.
  
  A transient Warning would be one in which the entity is currently experiencing an abnormal situation, but the situation should clear itself in a relatively short period of time and should not require human intervention. A printer-based example of a transient Warning would be something like "robot cleaner in action".
  
  The "transient" Warning type is not expected to be used by the vast majority of Publishers, but remains to fill a perceived (small) hole in the set of Conditions.
  
  Back to TOP
  
  Q44 -- What is the difference between an Operator and a Technician?
  
  Roughly speaking, an Operator would be responsible for the daily care and feeding of the managed entity; a printer-based example would be the person responsible for refilling consumables (paper, toner, etc) and emptying receptacles (paper bins, waste toner, etc).
  
  A technician would be a person with more formal and detailed training. The printer-based example would be the person responsible for hardware repairs and related activities that require more than a casual amount of time to learn.
  
  Back to TOP
  
  Q45 -- Do SENSE Servers know about each other?
  
  No, SENSE Servers are completely independent. No provisions have been made to "link" SENSE Servers together so as to provide a more comprehensive and cummulative view.
  
  Back to TOP
  
  Q46 -- Can a SENSE Server be a Client to another SENSE Server?
  
  One could easily build a small application that functions as a proxy agent between one SENSE Server and another. The agent can be a Client to one Server, subscribing to some or all Publications, then register those same Publications with another Server, publishing all Event Notices that it receives. A very simple example of such a SENSE proxy agent may be provided with the SENSE source code.
  
  Back to TOP
  
  Q47 -- Does a Publisher know about its Subscribers?
  
  No, a Publisher in general does not need to know about its Subscribers. A Publisher depends on the SENSE server reliably relay notices to all Subscribers.
  
  Back to TOP
  
  Q48 -- Can a Client discover the list of Subscribers on a SENSE Server?
  
  There is a specified but optional protocol message which can be used by a Client (either Subscriber or Publisher) to acquire the list of Subscribers; moreover, some events generated by the Server describe subscription activity. Implementers may or may not wish to include these capabilities, depending on security considerations.
  
  Back to TOP
  
  Q49 -- How can a Client monitor the activity of Subscribers on any given Sense Server?
  
  Subscription entries and lapses are both significant events in the SENSE Server, and they may be reported in the CommonSENSE protocol. Subscription activity events are included in a specified but optional portion of the CommonSENSE protocol. Implementers may or may not wish to include this optional protocol, depending on security considerations.
  
  Back to TOP
  
  Q50 -- Are SENSE Clients authenticated?
  
  No authentication or authorization mechanisms are currently defined within SENSE. Several approaches are being considered for a future version, however the initial release will not have any type of authentication and/or authorization facilities.
  
  Back to TOP
  
  Q51 -- What protocols are used in SENSE?
  
  The only explicitly defined protocol within SENSE is the "CommonSENSE" protocol used to report events within the SENSE Server itself, although Publishers may wish to employ the CommonSENSE protocol for their Publications if other protocols are not available or well suited.
  
  All other protocols used by Publishers to describe events are wrapped by the Server in SENSE Event Messages and relayed to Subscribers. The Server is not sensitive to the format of the Event Notices between Publishers and Clients.
  
  Back to TOP
  
  Q52 -- How would you characterize the wire format of the SENSE protocol?
  
  The physical encoding of SENSE protocol messages closely follows a format first employed by the Common Printer Access Protocol (CPAP) developed by Digital Equipment Corporation. Only a very minor interpretation of the CPAP specification was made to facilitate binary opaque event data.
  
  The encoding technique is such that is impervious to the typical "big-endian/little-endian" problems surrounding today's typical computer platforms. A possible exception is the potential presence of binary event data in an Event Message; the Subscriber must be able to interpret such binary data if interested in its contents.
  
  The bulk of a SENSE protocol message consists of a sequence of Properties that are encoded as a series of "named strings" with textual values. This method allows for a varying and arbitrary number of Properties to be included with any given message, resulting an a large degree of extensibility while maximizing compatibility.
  
  Back to TOP
  
  Q53 -- Where can I find out more about SENSE?
  
  Currently the bulk of the discussions surrounding SENSE are conducted on the Printer Working Group (PWG) electronic mailing list (pmi@hpbs987.boi.hp.com).
  
  A specific SENSE mailing list is expected to be created in the very near future. When that list becomes available a notice will be posted on the PWG mailing list.
  
  Of course, correspondence can also be sent directly to the authors at one of the addresses listed below.
  
  Author Contact Information:
  

  JK Martin jkm@underscore.com Underscore, Inc. 41-C Sagamore Park Road Hudson, NH 03051 Voice: 603-882-4826 Fax: 603-882-2699

  Richard Landau landau@hannah.enet.dec.com Digital Equipment Corporation 200 Forest Street (MRO1-2/J25) Marlboro, MA 01752 Voice: 508-467-8350 Fax: 508-467-6796

  
  
  
  Please send any comments or suggestions to the SENSE chairperson
  Last modified 3-November-1997.