Warrier, Besaw, LaBarre & Handspicker                           [Page 5]RFC 1189                     CMOT and CMIP                  October 19903.2.  The CMIP Protocol Suite   The following six protocols compose the CMIP protocol suite: ISO   ACSE, ISO DIS ROSE, ISO CMIP, ISO Presentation, ISO  Session and ISO   Transport.  The relation of these protocols to each other is briefly   summarized in Figure 3.                 +----------------------------------------------+                         Management Application Processes                 +----------------------------------------------+                             +-------------------+                                     CMISE                                 ISO 9595/9596                             +-------------------+                 +------------------+       +--------------------+                          ACSE                       ROSE                     ISO 8649/8650            ISO DIS 9072-1/2                 +------------------+       +--------------------+                 +-----------------------------------------------+                                ISO Presentation                                    ISO                 +-----------------------------------------------+                 +-----------------------------------------------+                                ISO Session                                    ISO                 +-----------------------------------------------+                 +-----------------------------------------------+                                ISO Transport                                    ISO                 +-----------------------------------------------+                      Figure 3.  The CMIP Protocol Suite3.3.  Conformance Requirements   A CMOT-conformant system must implement the following protocols:   ACSE, ROSE, CMIP, LPP, and IP.  A CMOT-conformant system must support   the use of the LPP over either UDP or TCP.  The use of the LPP over   both UDP and TCP on the same system may be supported.   A CMIP-conformant system must implement the following protocols:   ACSE, ROSE, CMIP, ISO Presentation, ISO Session and ISO Transport.Warrier, Besaw, LaBarre & Handspicker                           [Page 6]RFC 1189                     CMOT and CMIP                  October 19904.  Common Management Information Service Element   The Common Management Information Service Element (CMISE) is   specified in two ISO documents.  The service definition for the   Common Management Information Service (CMIS) is given in ISO 9595   [11].  The protocol specification for the Common Management   Information Protocol (CMIP) is found in ISO 9596 [12].  In addition,   the addenda for add/remove support in M-SET [32, 34] must be   supported for both CMOT and CMIP.  The addenda for M-CANCEL-GET [33,   35] may be supported by an implementation, but it's use is negotiated   as part of association negotiation.4.1.  Association Policies   The following ACSE services are required by CMISE: A-ASSOCIATE, A-   RELEASE, A-ABORT, and A-P-ABORT.  The rest of the CMIP protocol uses   the RO-INVOKE, RO-RESULT, RO-ERROR, and RO-REJECT services of ROSE.   There are four types of association that may be negotiated between   managing and managed systems.  These types are:      Event               M-EVENT-REPORTs may be sent by the                          managed system; no other CMIP PDUs                          are allowed      Event/Monitor       same as Event type except that, in                          addition, the managing system may                          also issue M-GET requests and                          receive M-GET responses over the                          association      Monitor/Control     managing system may issue M-GET,                          M-SET, M-CREATE, M-DELETE and                          M-ACTION requests over the                          association; no event reporting is                          allowed      Full Mgr/Agent      all functions must be supported   A conformant system  must support at least one of these Association   types.  Note that a system may play both managing and managed system   roles, but not on the same association.   The negotiation process uses the A-ASSOCIATE and A-RELEASE services.   Application Context Name is used to determine the requestor's "role"   in an association (as managing or managed system) and to determine   the type of the association.Warrier, Besaw, LaBarre & Handspicker                           [Page 7]RFC 1189                     CMOT and CMIP                  October 1990   The following values for Application Context Name are registered for   for CMOT and CMIP:      {iso(1) identified-organization(3) dod(6)           internet(1) mgmt(2) mib(1) oim(9) acn(1)           cmot1095(1)}           (for backwards compatible negotiation with RFC 1095 CMOT           implementations)      {iso(1) identified-organization(3) dod(6)           internet(1) mgmt(2) mib(1) oim(9) acn(1)           manager-event-association(2)}      {iso(1) identified-organization(3) dod(6)           internet(1) mgmt(2) mib(1) oim(9) acn(1)           manager-event-monitor-association(3)}      {iso(1) identified-organization(3) dod(6)           internet(1) mgmt(2) mib(1) oim(9) acn(1)           manager-monitor-control-association(4)}      {iso(1) identified-organization(3) dod(6)           internet(1) mgmt(2) mib(1) oim(9) acn(1)           manager-full-association(5)}      {iso(1) identified-organization(3) dod(6)           internet(1) mgmt(2) mib(1) oim(9) acn(1)           agent-event-association(6)}   The following negotiation rules are to be used:      1.   A managed system may only request an Event           association and, in fact, must create an Event           association if it has an event to report and no           suitable association already exists.      2.   Managing systems may request any association type.      3.   An association is created by the requesting system           issuing an A-ASSOCIATE request with the           requestor's AE-TITLE and the desired application           context.  The responding system then returns           either 1) an A-ASSOCIATE response with the           requestor's AE-TITLE and the application context           which it wishes to accept or 2) an A-ASSOCIATE           response rejecting the association.Warrier, Besaw, LaBarre & Handspicker                           [Page 8]RFC 1189                     CMOT and CMIP                  October 1990      4.   Managed systems may negotiate "downward" from           Full to Monitor/Control, Event/Monitor or Event by           returning the new application context in the           A-ASSOCIATE response to the managing system during           the association creation process.  In the same           fashion, managed systems may negotiate from           Event/Monitor to Event.      5.   When a managing system receives an application           context in an A-ASSOCIATE response that differs           from the context sent in an A-ASSOCIATE request it           may either proceed with the new context or refuse           the new context by issuing an A-RELEASE request.   A-RELEASE is used when the requestor does not agree with the new   context.  A-ABORT is used for invalid negotiation.  If A-ABORT were   to be used to terminate an association, there exists the potential   for loss of information, such as pending events or confirmations.   A-ABORT must be used, however, when a protocol violation occurs or   where an association is not yet established.4.2.  CMIS Services4.2.1  General Agreements on Users of CMIS   The general agreements on users of CMIS shall be as specified in the   OIW Stable Agreements [30] section 18.6.2.   The following additional agreements are specified.      o A system need only implement the services and service        primitives required for the association types (section 4.1)        that it supports.      o Current/Event times shall be fields shall use 1 millisecond        granularity.  If the system generating the PDU does not have        the current time, yet does have the time since last boot, then        GeneralizedTime can be used to encode this information.  The        time since last boot will be added to the base time "0001        Jan 1 00:00:00.00" using the Gregorian calendar algorithm.        (In the Gregorian calendar, all years have 365 days except        those divisible by 4 and not by 400, which have 366.)  The use        of the year 1 as the base year will prevent any confusion        with current time.        If no meaningful time is available, then the year 0 shall be        used in GeneralizedTime to indicate this fact.Warrier, Besaw, LaBarre & Handspicker                           [Page 9]RFC 1189                     CMOT and CMIP                  October 19904.2.2  Specific Agreements on Users of CMIS   The specific agreements on users of CMIS shall be as specified in the   OIW Stable Agreements [30] section 18.6.3.   The following additional agreements are specified:      o Event time shall be mandatory for all events.      o  Both the "managed Object Class" and "managed Object         Instance" parameters must be present in the following CMIS         Service Response/Confirmation primitives: the         M-EVENT-REPORT Confirmed, the M-GET, the M-SET, the         M-ACTION, the M-CREATE, and the M-DELETE.4.3.  CMIP Agreements   The CMIS and CMIP implementers agreements documented in the OIW   Stable Implementers Agreements [30] plus those mandated by the CMIP   standard will be used for both CMOT and CMIP.  In addition to these   implementers agreements, the following specific agreements must be   observed:      o An implementation is required to support all filter items        except subsetOf, supersetOf, nonNullSetIntersection, and        substrings.      o The "managedObjectInstance" field must be present in the        ProcessingFailure Error PDU.  The "managedObjectClass"        field must be present in the NoSuchArgument Error PDU.   [Temporary Note:  The CMIS/P implementers agreements have reach a   fairly stable status in the OIW working agreements document.  It is   expected that the CMIS/P agreements (18.6.2 and 18.6.3) will be   recommended to be moved into the stable agreements document during   either the June 1990 meetings.  Reference [30] points to the presumed   June 1990 updated version of the stable agreements document.]5.  Services Required by CMIP   The services required by CMIP shall be as specified in the OIW Stable   Implementors Agreements [30] section 18.6.5.   The following additional agreements are specified:      o ASCE Requirements:  Application contexts shall be as defined        in section 4.1 of these agreements.  The values and defaultsWarrier, Besaw, LaBarre & Handspicker                          [Page 10]