(PWG) SENSE Meeting, 21-22 Feb. 1996 Held at Dataproducts, Simi Valley, CA A subset of the Printer Working Group met on 21-22 February 1996, near Los Angeles in a facility provided by Dataproducts, to work on the requirements and specification of the Simple Event Notification Service Environment (SENSE). All PWG members were invited to participate. These minutes will be published to the PWG mailing list (the "pmi" list). NOTE: The text of these minutes is extremely terse and may be a bit confusing to those not present at the meeting! Wednesday, 21 February 1996. Meeting started at 08:30. Attending: Ron Bergman, Dataproducts (host) Bergi Bagdasarian, Dataproducts Lee Farrell, Canon Andrew Garsten, Dataproducts Rick Landau, Digital (minutes) Jay Martin, Underscore (convener and chairperson) Hoang Nguyen, Xerox Bill Schatz, Dataproducts Tong Sun, Xerox Mike Timperman, Lexmark Kurt Van Laar, Dataproducts Gregg Welker, Dataproducts Proposed Agenda Items (in no particular order): o Should SENSE be done at all? o Problems that need to be addressed? o Requirements o Comparison of SENSE with Party MIB o Performance goals and expectations o How does SENSE differ from competing technologies, e.g., SNMP Party MIB, X/Open's Event Mgmt Service, etc.? o Integration models, platforms, and issues o How does the protocol actually work? o API specs, usage, programming model, how to incorporate in real products o What is the difference between subscription and registration? Introduction: Jay Martin spoke about the history and motivations of SENSE, frustrations with existing network notification methods. o Underscore is very apprehensive about releasing a Printer MIB product that requires too much network bandwidth due to polling. Instead, a better approach would be to have a single small Printer MIB monitor agent keep track of a target printer, then forward all interesting events to a SENSE server that can provide scalable fanout. o Must have a SENSE reference implementation in the market. Underscore will do that. Will printer vendors adopt it? o Is the success of SENSE dependent on industry acceptance of the Printer MIB? No. SENSE can even provide leverage for legacy products that don't do Printer MIB, or even any MIB. If there is some way to get the "overall health" status of the printer, then SENSE can be used to publish this status. o Party MIB: even though it has been removed from SNMP V2(C) some vendors may still implement it, and it is intended for similar purposes. How do these relate? Xerox, at least, has implemented the Party MIB and wants to know what benefits it would derive from implementing this other technology. - The Party MIB solves only some of the problems with notification, and only in the context of SNMP. It helps with dynamic registration and non-privileged reply addresses for SNMP traps, but does not help with reliability of notices. Registration vs subscription: o Client registers with Server, then can subscribe and unsubscribe to Publications as it wishes. The registration is timed. The client can change its subscription list. The client must renew before the end of the registration period, but the server can assist the client by sending out an "ExpirationNotice" message to "remind" the client to send the Renew request. o Does the Server register with name services in the network? Possibly, but the design should NOT require such dependence. Action: Landau will write strategy for finding SENSE servers in the network, fallbacks ranging from name service registration to ping-spray discovery. Questions in random order: o Q: What is a Publisher? A: An agent that mediates between a source of events, e.g., an SNMP agent sending traps, and the SENSE Server, which is a forwarding service. o Q: How does the client find out about all the devices? A: Request the list of currently registered Publications. o Q: How does a client find out about all power-up traps for devices (that is, find out when a new device is available)? A: It doesn't directly. It looks for new Publications. Publications may be persistent, i.e., optionally continue to exist even when the Publisher isn't there. In order to present a consistent view of the world, it is best if the Publishers are able to make publications persistent. o Q: How about replacing failed device with an equivalent device? How does one destroy the old, persistent publication? A: Probably don't need to. Publications have administratively-assigned names, not like ethernet addresses that change with replacement. So the replacement for printer "Joe" will still be named "Joe" and therefore its Publication name won't change. o Q: Shelf life: do Publications have a declared or implicit shelf life that limit their persistence? A: Reasonable idea, let's consider it. o Q: Regarding the "SENSE Universe" diagram, what is an Event Gateway Agent? A: A specialized client designed to connect Servers together, if that is necessary, rather than complicate all Servers by including that function in the base. It may be useful to cascade Publications and Event Notices from one Server to another for easier access by clients. o Q: Is this gateway included in the base implementation? A: Underscore will try to include it in the first release, but can't guarantee it. This should not be difficult, will make a good test for how easy this is to write a simple re-publishing client. o Q: What is the translation agent? Just a semantic mapper from one syntax to another? A: Yes. It's hard to come up with a lot of examples that work, but the intention is that one be able to map equivalent semantics from one syntax and synchronicity to another. o Q: Is CPAP a public standard? A: Yes, not proprietary to Digital (but not implemented by others yet). The document is on the Lexmark ftp server; Jay will upload it to the HP PWG ftp server, too. SENSE doesn't use CPAP directly, only the "framing mechanism" of the CPAP wire representation. o Q: How does this relate to DCE RPC? A: It doesn't relate at all. CPAP is a message stream based protocol, suitable for printing but not limited to it. SENSE takes only the framing method and data representation from CPAP. o Q: What is an Object in SENSE? A: Object = named set of properties. "Active" vs "passive" distinction objected to, suggested that the documents change to "dynamic" vs "static" objects. o Name space administration: want hierarchical space for names, like OIDs but with strings instead of numbers, sort of like X11 resources. Example: FirstName=Jay LastName=Martin becomes Name.First=Jay Name.Last=Martin o The SENSE spec will list the standard property names of the standard objects. Vendors can assign others, of course. Clients are required not to barf on properties they don't know about. In particular, arbitrary descriptive string properties for Publications are probably very interesting and useful, and are easily displayed by a subscriber application. o SENSE could be used to publish a stream of messages that, for instance, mirrored the SNMP SetResponse messages, so that Subscribers could watch to see what MIB objects had changed as a result of a Set operation by someone else. An application might be interested in, for example, any time someone set the value of a prtInputMediaName MIB object. o Q: Relationship to ASN.1 BER? A: None in the first version. If someone wants to pursue that as a research project to improve network efficiency in V2, good idea. (In my experience, ASN.1 programming is not easier or faster than parsing the strings in the proposed protocol. --RBL) o Q: Relationship to DMTF? A: Do they have anything interesting we can use? Their hierarchy is System, Component, Group, Attribute, and that's probably quite deep enough for us. Chalk-talk on Editions: o Edition = variation of Publication, arbitrary binding of several dimensions (examples: syntax, content). o Q: Could these just be separate publications? A: Yes, we started out that way, but changed to keep Publications one-to-one with managed entities. It is useful to have an object you can enumerate that corresponds to a managed entity. Otherwise, it is difficult to determine algorithmically what the list of entities is. Humans can read the strings, but programs might not be able to. So, one Publication per managed entity, but potentially a number of Editions per Publication. o Q: How is Edition specified, how does the client find out the characteristics of Publications to choose among them? A: Haven't decided yet. Uniqueness might be in the Edition name or only in properties. The SENSE Server will assign a numeric handle to all objects for processing efficiency, but description attribute and other properties are always available in attribute list. o Basic Edition: the simplest CommonSENSE Condition status changes. Each Publisher can assert that it can publish the Basic Edition. Not clear yet what the policy is (or policies are) for deciding whose Basic Edition to publish, what happens when that Publisher goes away, etc. (Maybe condition goes to Unknown. Don't know yet. Hope to find out in prototyping.) o There is always at least one Publication, the Server's own Publication about its own status. A client can always sit there waiting for a target Publication to show up, presumably when the Entity initializes. o Can have a Publication that corresponds to a non- physical Entity. Example: some Publisher rolls up the overall status of a group of other Entities, such as green-light-red-light for a *group* of printers. o [Why isn't Edition a reasonably inherited object from Publication? I still don't understand. This is another conversation that Jay and I have to have with whiteboards and paper.] Review of latest document: o Requirements: - Retries for delivery: is this an attribute for the server, for the client Registration, for the Subscription, for the Publication, what? There really is no Subscription object in the server code at the moment, but this may have to change. - R3 and R4: give examples of port numbers for various transports to minimize confusion. - Check document on Draft IETF Service Location protocol that Andrew found. May provide another method for discovering some network objects. Internet-Draft document draft-ietf-svrloc-protocol-10.txt probably on Internic. o Third-party Subscription? Spoof-able in several different ways, bad idea. Do not permit this. o Q: How does SENSE interoperate with CORBA and XEMS event services? The transmission of semantic-free opaque data makes interoperability difficult. A: Needs research to determine what a gateway could accomplish that would be useful. o DMTF has published V1.1 spec with a new model of events and notification, apparently fairly complex. Everyone should read this. o Q: How about duplicate editions? How do Publishers avoid name space collisions, or how are those resolved? A: Not decided yet. The Server can be written either way. Need to decide what the possibilities are, so that the clients can be written one way or the other (duplicates allowed or not). Editions are good for extensibility, reduce the administrative effort in handling a flat name space. o Q: Why have a "transient" client? What additional function comes from this distinction? A: This is just a shorthand that describes what messages are allowed for non-registered users. Not a big deal. Permits potential Subscriber clients to browse Servers for interesting Publications without going through the extra effort of registering and deregistering. o Q: Is transient activity always permitted? A: No, it may be ruled out by local policy. Also, registration my involve real authentication with real passwords and such. (This is a "marketing opportunity" for vendors.) o Put in reminder that a SENSE session does not consume a connection resource. o A Server might elect to require authentication cookie for some directory operations (and others) on some objects for security reasons. o Basic Edition = small, simple set of event messages using a syntax similar to the CommonSENSE protocol; used to indicate changes in the Publication "condition", update the Publication properties, etc. o Conditions: glossary needs work. Describe basic set of conditions in the text, with the various levels of basic condition maybe required, with user extensions permitted. Finished review of doc. Meeting ended at 18:30, to reconvene at 08:30 Thurs. ------------------------------------------------------------ Thursday, 22 Feb 96. Meeting started 08:35. Attending: Ron Bergman, Dataproducts, host Bergi Bagdasarian, Dataproducts Lee Farrell, Canon Andrew Garsten, Dataproducts Rick Landau, Digital Jay Martin, Underscore Hoang Nguyen, Xerox Bill Schatz, Dataproducts Tong Sun, Xerox Mike Timperman, Lexmark Kurt Van Laar, Dataproducts Gregg Welker, Dataproducts Remaining agenda items from yesterday: o Performance goals and expectations o How does SENSE differ from competing technologies, e.g., SNMP Party MIB? o Integration models, platforms, and issues o How does the protocol actually work? o API specs, usage, programming model, how to incorporate in real products Dimensions of performance: o Reliability: - Lots better than SNMP, where traps can be used only to accelerate polling. - A sane person *would* build a service- critical application on this service, because you can tune the reliability (retry rates and limits) as high as you need it. - Server can be built to store and forward messages on persistent storage so that messages don't get lost even across server crash. SENSE protocol does not get in the way of this, so reliable server could be built for applications that need it. - Xerox experience with UDP packet loss is about 2%. Landau's measurements on the network have ranged from a low of 2% to 30+% on a busy segment. o Network traffic generated: - Length of user sessions is tunable. - Expiry warning messages should be tunable or defeatable to minimize traffic. - Expiry warning has no ACK, so that's not much of a burden. - Total traffic is very low relative to *any* level of polling. - ACKs not a problem, because they're so much lower than any level of polling would be. - ASCII nature of wrapper protocol not a problem because of limited number of properties added to the wrapped message. Opcodes being numbers instead of names helps a lot. o System size: number of Editions. Several editions may be available per Publication. Example set of Editions for a Publication describing a printer: - Basic (changes in condition, properties) - Operator (with fault diagnostic info) - Job info - All info - A couple different syntaxes: SNMP traps and private syntax for events - Total maybe 25-ish Editions per Publication max; typical number more like 5-ish Editions per Publication. o System size: number of Subscribers. - Embedded server: probably 10 to 50 Subscribers, workgroup size. One Publication for that device, so more like ten Subscribers than fifty. - External Server, probably 500 to 1000 registered clients max. o System size: Publications - Probably 20-50, about 20x Subscribers per publication max. o Delivery timing: - Could hardly be worse than *any* polling mechanism, where average delivery time is half the polling interval. Forwarding time through a Server, even with high fanout, will probably be much less than one second. - Typical polling rates probably 30-60 seconds. Some opinions put reasonable rates as low as 10 seconds, some as high as five minutes. For mechanical failures such as paper-out or printer jammed, rates on the order of minutes might be marginally acceptable. - Multiplicative effect of more people polling more printers will be a disaster; this async mechanism might allow us to avoid the coming avalanche. - High fanout might require rate limiting when forwarding an event to large number of users, hundreds of UDP packets back to back. o Cascading SENSE Servers can work to increase fan-out or to concentrate Publications. - Can cascade one set of Publications and Editions to a set of Servers so that, e.g., each LAN segment, subnet, or other workgroup can have a local Server for interesting publications. - Can concentrate a number of Publications from separate Servers into one Server, for instance, one local SENSE Server publishing events for a number of embedded Servers. Other competing technologies: o Party MIB o ToolTalk o X/Open EMS o Standard NMS products o CORBA Event Services o Modify wording in the requirements section of "no standard mechanism," because Party MIB does do dynamic registration and destination port problems; however, it is not expected that most vendors will implement the Party MIB, so availability is an issue. SENSE, however, must also deal with non-SNMP environments, so the Party MIB is not suitable for those other environments. Criteria for comparison: SNMP-ness, suitability for non-SNMP implementations, availiability on variety of platforms, unit cost, etc. Must address naming and discovery: how do clients find servers? o Have to design strategy to work with complex systems but also with very simple mechanisms, such as well- known file containing config data. o Start with high tech solutions like name services, fallback if high tech things aren't available. A SENSE Server with persistent Publications could easily act as a simple name service for all publications in an area. o Action: Landau to write up strategy for this for next version of document. Example protocol sequences: 1. Typical user-level "Traffic Light" status application: Subscriber Client SENSE Server ---------- ------ ----- ------ (program start) Get PublicationIdList Reply (for each publication) GetPublicationProperties (interesting properties include Class, Type, AssignedName, Condition, LastErrorEventMessage, etc.) Reply (for each edition of each interesting Publication) GetEditionProperties Reply (then if there is any edition you want) RegisterSubscriber Reply Subscribe Reply (some time later maybe) Event Reply (maybe a lot of events from the Server) (some time later maybe) ExpirationWarning Renew Reply (later) UnregisterSuscriber Reply 2. Publisher: Publisher Client SENSE Server --------- ------ ----- ------ RegisterPublisher Reply RegisterPublication (later maybe) PublishEvent Reply (lotta these, server forwards) UnregisterPublication (maybe not if persistent pub) Reply UnregisterPublisher Reply How to get basic Condition info: o Remember to get the Condition property when requesting a Publication's properties. This is the current overall status ("health") of the Publication. o If Condition is not "green", and your application cares, then get other info, either from properties registered with SENSE by the Publisher, or by some other mechanism. o Publishers should include some properties that give more information for "red" and "yellow" conditions, at least something human-readable. Publishers of printer events could agree on a set of named properties that give the overall status of the various printer subunits. This would permit simple clients to get enough status for non-trivial "Traffic Light" applications without the use of any other protocol! Properties: o Standard, mandatory, publication-independent set of properties o Standard, mandatory, class-dependent set o Publication-specific set o Naming conventions for properties - Use the X11 resource model, sort of, but maybe not quite so anal about inheritance of properties. - The only wildcarding for v1 will probably be a trailing "*" Standard properties, mandatory, publication-independent: o Most of the items from MIB-II System Group - sysObjectID - sysDescription - sysUpTime - sysName - sysLocation - sysContact o Most items from DMTF Component ID Group - Manufacturer - Version - Installation (date/time the managed object was installed) - Class - Product - Serial Number - Verify Class is suggested by DMTF to be the concatenation of | | o According to DMTF, groups that share class name must have the same attribute ids, datatypes, access, storage, etc., i.e., they have to be structurally identical. Gives a reasonable guideline for when to update this string when releasing new product versions. Protocol questions: o Q: Does the Server reformat event messages? A: No, the Server enhances event messages only by adding time stamp and server-centric message id. o Q: Does a potential Subscriber have to examine all the Publications to find the few it may be interested in? A: As currently specified, yes. We may wish to enhance the GetPubIdList request message to add "with Class=Printer*" or some such very simple search arguments to minimize Publication property fetching and processing by client applications. o Q: How can a client look at previous events that were sent before the client came online? A: A logging/history mechanism is easily layered on SENSE, but not clearly related to an event mechanism. It is conceivable that one could add a protocol for it, but it is better implemented as a separate layer. Also, don't put the burden of history on the Publisher. Times kept for Publications: o Created o Modified o Installed o Don't keep actual sysUpTime, of course, but only time stamp when publication started. o May also keep track of last Publisher that last modified the Publication, for diagnostic purposes. Property names: o Probably Pub.Location, Pub.Manufacturer o Lots of derived properties, too, that the server creates: Editions.IdList, Pub.PublisherId, other properties used to aid internal management by the server. Standard vs Mandatory properties: o Mandatory = you, the Publisher, must supply the attribute name and value to the Server. o Mandatory = the attribute value is always available to Clients. Agenda items for the future: o Clear definition of the names and contents of properties. o Request large block of time at next PWG meeting to discuss SENSE progress, educate other members. Meeting adjourned 1:30. # # # # #