Stable Implementation Agreements for Open Systems Interconnection Protocols: Part 6 - Registration Authority Procedures for the OSE Implementors Workshop (OIW) Output from the December 1993 Open Systems Environment Implementors' Workshop (OIW) SIG Chair: Einar Stefferud, Network Management Associates, Inc. SIG Editor: Brenda Gray, NIST PART 6 - REGISTRATION AUTHORITY PROCEDURES FOR THE OSE IMPLEMENTORS' WORKSHOP (OIW) December 1993 (Stable) Foreword This part of the Stable Implementation Agreements was prepared by the Registration Special Interest Group (RSIG) of the Open Systems Environment Implementors' Workshop (OIW). This part replaces the previously existing chapter on this subject. Future changes and additions to this version of these Implementor Agreements will be published as change pages. Deleted and replaced text will be shown as strikeout. New and replacement text will be shown as shaded. ii PART 6 - REGISTRATION AUTHORITY PROCEDURES FOR THE OSE IMPLEMENTORS' WORKSHOP (OIW) December 1993 (Stable) Table of Contents Part 6 - Registration Authority Procedures for the OSE Implementors' Workshop (OIW) . . . . . . . . . . . . . . 1 0 Introduction . . . . . . . . . . . . . . . . . . . . . . 1 1 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2 Normative References . . . . . . . . . . . . . . . . . . 2 3 Registered Information Objects . . . . . . . . . . . . . 2 4 Registration Procedures for Object Identifiers . . . . . 5 4.1 SIG Registration Authorization . . . . . . . . . . . 5 4.2 SIG Registration Authority Function and Duties . . . 5 4.3 Requirements for Information Object Registration . . 5 4.3.1 Assignment of Object Identifier Component Values . . . . . . . . . . . . . . . . . . 5 4.3.2 Proposal of Object and Identifier to Plenary . . . . . . . . . . . . . . . . . . 6 4.3.3 Completion of Registration Procedure . . . 6 4.3.4 Changes and Revisions to the Information Object Registration . . . . . . . . . . . 6 4.4 Register Index . . . . . . . . . . . . . . . . . . . 6 Annex A (normative) Assignments to Workshop Organizations . . . . . . . . . . . . 7 Annex B (normative) Status of 1987 and 1988 Ad-hoc Object Identifiers . . . . . . 8 Annex C (informative) Guidelines for Registering Changes to Technical Objects . . . 9 C.1 Evaluating Registered Technical Objects . . . . . . 9 C.2 A Registration Review Criteria . . . . . . . . . . . 11 C.2.1 The Technical Object Description . . . . . 11 C.2.2 Evaluating the State Values . . . . . . . . 13 C.2.3 Evaluating the Data Structure . . . . . . . 13 C.3 The Change Process . . . . . . . . . . . . . . . . . 14 iii PART 6 - REGISTRATION AUTHORITY PROCEDURES FOR THE OSE IMPLEMENTORS' WORKSHOP (OIW) December 1993 (Stable) List of Figures Figure 1 - Structure of Object Identifier for OIW. . . . . . 4 Figure 2 - Structure of an Object Identifier for an Example Object for the Registration Authority SIG of OIW. . . . 4 iv PART 6 - REGISTRATION AUTHORITY PROCEDURES FOR THE OSE IMPLEMENTORS' WORKSHOP (OIW) December 1993 (Stable) List of Tables Table 1 - Index Entry Example . . . . . . . . . . . . . . . . 6 Table 2 - Identifier Assignments . . . . . . . . . . . . . . 7 v Part 6 - Registration Authority Procedures for the OSE Implementors' Workshop (OIW) NOTE - Previous material in this section has been deleted and is no longer applicable. This chapter establishes the policies and procedures for the registration of technical objects defined by the OSE Implementors' Workshop. Procedures for registering operational and administrative objects, such as the MHS ADMD and PRMD names and addresses, are outside the scope of this chapter. 0 Introduction In order to communicate, it is necessary to identify the objects involved in communication. These objects have names and addresses. A name identifies an object within the domain of a registration authority. An address is a name that is used to specify the physical or logical location of an object. OSI names and addresses consist of attributes which are hierarchical in nature and which combine to identify or locate an OSI object unambiguously. Since the relationship between the components of a name or address is hierarchical, it follows that the registration authority for names and addresses should also be hierarchical. A governing organization does not always have sufficient knowledge of organizations lower in the hierarchy to assign values within those organizations. Thus, an approach frequently taken is to delegate registration authority to the lower organizations. Hierarchy implies an inverted tree-like structure where the number of objects increases from the root of the tree to the leaves of the tree. At the root of the tree, there is one designator that has the greatest scope of authority (largest domain). This designator assigns identifier values to objects under its authority. Each of these objects has a smaller scope of authority than the objects immediately above and may create zero, one, or many subauthorities at the next-lower level. The number of levels in such a tree-like structure is arbitrary. 1 PART 6 - REGISTRATION AUTHORITY PROCEDURES FOR THE OSE IMPLEMENTORS' WORKSHOP (OIW) December 1993 (Stable) 1 Scope This part defines registration procedures for OSE Implementors' Workshop (OIW) information objects and identifies additional registration requirements. These procedures shall be used by the Special Interest Groups (SIGs) of the Workshop to register information objects used in OSI communications according to the OIW Agreements Document. In this part, the OIW and the SIGs themselves are assigned arcs in the object identifier tree. These arcs are for OIW-specified objects. The SIGs should note that, as national and international registration authorities are established, objects of interest beyond the Workshop are more appropriately registered by a higher level in the hierarchy. This will allow more widespread acceptance of the registered objects. This part is structured as follows: 6.2 describes the information objects that need to be registered, and 6.3 describes a registration procedures for OIW object identifiers. Annex A lists the object identifier component values assigned to the OIW and the SIGs. Annex B discusses object identifiers used in the 1987 and 1988 Stable Implementation Agreements. Annex C presents guidelines for registering changes to technical objects. The appendices are integral parts of this specification. 2 Normative References 3 Registered Information Objects If networks are to interoperate as envisioned in the OSI model, there must be a universal open and agreed upon naming schema. There are many information objects that fall under this requirement. Some of the following objects are registered in the standards, some are registered by OIW and others by other registration authorities. An example list of objects to be registered is: a) Application-process-titles; b) Application-entity-titles; c) Abstract syntaxes; d) Transfer syntaxes; 2 PART 6 - REGISTRATION AUTHORITY PROCEDURES FOR THE OSE IMPLEMENTORS' WORKSHOP (OIW) December 1993 (Stable) e) Application-contexts; f) MHS; 1) ADMD names; 2) PRMD names; 3) Organization names; 4) Encoded information types; 5) Extended body part types; 6) Extensions; 7) etc.; g) Object Identifier values; h) ASN.1 modules; i) Directory; 1) Relative distinguished names; 2) Attribute types; 3) Attribute syntaxes; 4) Object classes; 5) Encryption algorithms; 6) etc.; j) VT; 1) Profiles; 2) Reference information objects; 3) etc.; k) Network management objects; l) Network layer addresses; m) System titles; 3 PART 6 - REGISTRATION AUTHORITY PROCEDURES FOR THE OSE IMPLEMENTORS' WORKSHOP (OIW) December 1993 (Stable) n) FTAM; 1) Document types; 2) Constraint sets; 3) etc.; o) etc. The OIW Registration Authority shall only administer information objects created by the OIW Agreements Document that are identified by the ASN.1 type OBJECT IDENTIFIER. Figure 1 illustrates the structure of the object identifier component value for OIW. +---------------------------------------------------------------+ | ( iso identified-organization oiw (14) ) | | | | iso(1) | | | | identified-organization(3) | | | | oiw(14) | +---------------------------------------------------------------+ Figure 1 - Structure of Object Identifier for OIW. As an example figure 2 shows the object identifier component value for an example object. +---------------------------------------------------------------+ | ( iso identified-organization oiw(14) rasig(13) example(0)} | | | | iso(1) | | | | identified-organization(3) | | | | rasig(13) | | | | example(0) | +---------------------------------------------------------------+ Figure 2 - Structure of an Object Identifier for an Example Object for the Registration Authority SIG of OIW. The ISO 6523 Registration Authority has assigned an International Code Designator (ICD) value of 14 to OIW, and OIW has assigned a unique object identifier component value to each SIG. The assigned object ID values for the OIW and for each SIG are in Annex A. The assignment of values below each SIG in the object 4 PART 6 - REGISTRATION AUTHORITY PROCEDURES FOR THE OSE IMPLEMENTORS' WORKSHOP (OIW) December 1993 (Stable) identifier tree is the responsibility of that SIG. 4 Registration Procedures for Object Identifiers This clause specifies the responsibilities of each SIG and the procedures to be followed for the registration of information objects, and submission to the OIW Plenary. When an OIW SIG defines an information object the SIG shall register the object identifier. The registered value shall be incorporated into the appropriate OIW Agreements Document as a result of a positive ballot response of the OIW Plenary. 4.1 SIG Registration Authorization An OIW SIG is authorized by its charter and the scope of its work to submit a registration request to the OIW Plenary. 4.2 SIG Registration Authority Function and Duties The SIG Chair is responsible for the assignment, recording and maintenance of the SIG's registered objects. The SIG Chair may appoint a specific person to carry out the SIG duties and responsibilities. 4.3 Requirements for Information Object Registration 4.3.1 Assignment of Object Identifier Component Values Each SIG shall register an object identifier component value for each object's technical definition. The NameAndNumberForm of the ObjIdComponent specified in ISO 8824/CCITT X.208 is used exclusively. This form comprises an ASN.1 identifier and, significantly, a NumberForm. It is suggested that the SIG assign a monotonically increasing integer to the NumberForm at any given level. To the significant root the SIG shall add a assigned object identifier component value that shall be unique. An example of an object identifier created by the RASIG is shown as follows: {iso(1)identified-organization(3) oiw(14) rasig(13) example(0)} Here rasig is the SIG identifier and 13 is the NumberForm 5 PART 6 - REGISTRATION AUTHORITY PROCEDURES FOR THE OSE IMPLEMENTORS' WORKSHOP (OIW) December 1993 (Stable) assigned by the OIW Registration Authority (see Annex A); example is the identifier and 0 is the NumberForm assigned by the RASIG. 4.3.2 Proposal of Object and Identifier to Plenary Registration of an object identifier and its definition is proposed by inclusion of the object identifier and its definition in the OIW "Working Implementation Agreements" document. 4.3.3 Completion of Registration Procedure Registration of an object identifier and its definition is completed upon Plenary vote to move "Working Implementation Agreements" text which contains the object identifier and its definition to the "Stable Implementation Agreements" document. 4.3.4 Changes and Revisions to the Information Object Registration Neither the technical definition nor the object identifier shall be changed or modified after registration i.e., after the definitions and their identifiers have been voted into the "Stable Implementation Agreements" document. 4.4 Register Index Each SIG shall maintain an index of object identifiers that point to the technical definitions of the respective objects in the OIW Agreements Document. The index shall appear in the appropriate part annexes of the OIW Agreements Document. Table 1 - Index Entry Example Object Identifier Referen ce iso identified-organization 4.3.1 oiw(14) rasig(13) example(0) 6 PART 6 - REGISTRATION AUTHORITY PROCEDURES FOR THE OSE IMPLEMENTORS' WORKSHOP (OIW) December 1993 (Stable) Annex A (normative) Assignments to Workshop Organizations Table 2 - Identifier Assignments Ident Val Assigned Assigned By ifier ue To oiw 14 OIW ISO 6523 RA llsig 1 SIG OIW nmsig 2 SIG OIW secsi 3 SIG OIW g tpsig 4 SIG OIW ftams 5 SIG OIW ig mhsig 6 SIG OIW dssig 7 SIG OIW ulsig 8 SIG OIW rdasi 9 SIG OIW g mmssi 10 SIG OIW g odasi 11 SIG OIW g vtsig 12 SIG OIW rasig 13 SIG OIW hcsig 14 SIG OIW ctsig 15 SIG OIW 7 PART 6 - REGISTRATION AUTHORITY PROCEDURES FOR THE OSE IMPLEMENTORS' WORKSHOP (OIW) December 1993 (Stable) Annex B (normative) Status of 1987 and 1988 Ad-hoc Object Identifiers In the 1987 and 1988 versions of the Stable Implementation Agreements, a number of OIW-specified information objects are assigned object identifiers. OSI requires names and addresses, e.g., object identifiers, be globally unambiguous. This chapter specifies object identifier component values which are globally unambiguous. Other chapters in this document specify the correct object identifiers to be used when referencing OIW-specified information objects. The use of the 1987 and 1988 OIW-specified object identifiers is deprecated. Newly defined objects shall use the new OIW Identifier. 8 PART 6 - REGISTRATION AUTHORITY PROCEDURES FOR THE OSE IMPLEMENTORS' WORKSHOP (OIW) December 1993 (Stable) Annex C (informative) Guidelines for Registering Changes to Technical Objects Part 6 of the OIW Agreements document describes the process for registering technical information objects that are defined in the development of OIW implementation agreements. However, the process does not describe a criteria for determining when a change to an object definition is of sufficient magnitude to require registration of a new object with a new OID. Such criteria would be useful when changes are proposed to technical object definitions that have already been registered. The registration procedures for technical information objects in OIW Implementation Agreements assumes that each object is uniquely different in particular ways from all other registered technical information objects, and requires that there is exactly one definition for each registered object identifier (OID). Therefore, when an object definition is to be changed, it must receive a new OID if the change is "sufficiently significant," in order to signal to all concerned parties that something significant has been changed. The purpose of this tutorial section is to provide a guide for the evaluation of proposed changes to the definition of a technical object. Many of the changes will fall in a gray area between an obvious "editorial change" with no change to the operational characteristics of the registration and "significant change" that will require the requested change to be registered as a new technical object with a new Object Identifier (OID). These guidelines are presented to assist in providing a consistent approach for reviewing requests and making changes to any registered technical object. C.1 Evaluating Registered Technical Objects Technical objects in the OIW registers include a functional definition describing the object, its states and the actions that can change the object's states. The definition and actions of the object are usually presented as descriptive text, while the state may be defined by a data structure and a set of values such as constants or ranges, having a particular syntax. It should be recognized as stated above that modifying or deleting one or more parts of the definition may not be of sufficient importance to require the registration of the registered technical object under 9 PART 6 - REGISTRATION AUTHORITY PROCEDURES FOR THE OSE IMPLEMENTORS' WORKSHOP (OIW) December 1993 (Stable) another identifier (OID). For example, we should note that sometimes a change may be desired to specifically reduce confusion that stems from different interpretations of a given definition. In this case, the change might require some implementations to be modified to conform to a chosen interpretation, but who is to say that the definition was changed, versus saying that the original intent was finally made clear? It is a matter of judgement by the responsible OIW SIG to decide whether a new OID should be assigned in this case, or not. When a change is sufficiently significant to require a new OID, then the old object must remain unchanged with its old OID. 10 PART 6 - REGISTRATION AUTHORITY PROCEDURES FOR THE OSE IMPLEMENTORS' WORKSHOP (OIW) December 1993 (Stable) Review criteria must consider the relative importance of the parts of the technical object definition that are affected by a change before determining whether to approve the proposed change. Deciding not to accept a proposed change may result in a need to create a new technical object very similar to the one being reviewed. C.2 A Registration Review Criteria The significant components of the technical definition, to which a criteria can be applied include the text description of the technical object, the definitions of the state values, and the definitions of the data structures. The criteria is not intended to be regulatory in nature, but to provide some direction in reviewing each of the three components when evaluating change requests for registered technical objects. C.2.1 The Technical Object Description Does the proposed definition change or require a uniquely different set of functions or state conditions, or does the proposed change alter the relationship between functions of the registered object? If the proposed definition change adds another function or creates another state, or modifies the relationship between functions or state conditions of the object, or deletes a defined function or state condition then the proposed change should be registered as a new technical object with a new OID, provided that the proposed change would have a significant impact upon the implementation or operation of the technical object when changed. Editorial changes can be made to correct grammatical errors or to improve clarity, without changing the definition. For changes that require additions or deletions of text to the definition, an evaluation must be made to determine if the changes when applied are optional or will apply only to a local implementation, or are extensive enough to require a new implementation. Deciding what change means with respect to the functional definition is a subjective view and will require that each SIG establish some guidelines for its particular object types. Consistency of application of a registration policy within each SIG would be most helpful to the process. One approach is to rule that any change, other than a spelling or 11 PART 6 - REGISTRATION AUTHORITY PROCEDURES FOR THE OSE IMPLEMENTORS' WORKSHOP (OIW) December 1993 (Stable) grammar change requires a new technical object registration. However, the consequence of such a rule would be a large number of registered technical objects with very similar definitions that can create considerable confusion for implementors. The opposite position is to treat any change to the functional description as an editorial change, and only changes to the other criteria like the state values or data structures are evaluated to make a decision about registration of the changed object as a new technical object. Between the two is a more acceptable view that provides for the evaluation of the proposed change to decide whether the change is editorial only, NOT affecting implementation; or if it is a change in functionality that MAY affect implementation. If it does NOT affect implementation, then it is an editorial change. If it MAY affect the implementation, then the change requested should be evaluated for registration as a new technical information object with a new OID. An Example: Change #1. A given registered object includes a range of values for a particular attribute called TIMEOUT. It includes the following two facts: a) a definition of the TIMEOUT attribute; b) the range of values for the TIMEOUT attribute. If the range of the TIMEOUT attribute is changed from 10..100 to be 10..1000, it is possible that the change is not significant enough to warrant a new registration, if the parameter is only applied locally. (We will assume that this is the case for this example.) Change#2. Suppose the same attribute is to be deleted. Then some assessment is needed, regarding the impact of the change to the global operational environment in which the technical object is to function, to determine if a new registration is required with a new OID. The relative significance of the two changes to the operational requirements are clear (given our assumptions here) in these two cases. Changing the values of the range of the TIMEOUT parameter is a relatively minor change which affects only local operation. Depending on other operational considerations, and the relation of the TIMEOUT to other facts about the technical object it could be changed without a new registration. But the elimination of the TIMEOUT attribute altogether would be much more significant, and more than likely require a new registration, since current implementations would be expecting the existence of such an 12 PART 6 - REGISTRATION AUTHORITY PROCEDURES FOR THE OSE IMPLEMENTORS' WORKSHOP (OIW) December 1993 (Stable) attribute in any operating environment, and future implementations would not include it. C.2.2 Evaluating the State Values Within the registered technical object description there may be a number of constants, ranges of values, and syntaxes specifically defined for the object. They are all subject to change. The evaluation criteria applied to requests for changes to state values has to consider the kind of operation that the technical object is performing. EXAMPLE: The range of accepted values is changed from 1-128 to 0-127, or the default value of a parameter is changed from 32 to 128. Understanding the implications of what is changing helps to measure the impact of the proposed changes. The shift of the range from 1-128, to 0-127 could be trivial, depending on the scope of its use and would not alone necessarily warrant a new registration. However to change a default value from 32 to 128 (if the attribute applies to the availability or limit of some external system or network resource) would clearly be cause for much concern over how the change impacts implementations of the technical object. C.2.3 Evaluating the Data Structure Each technical information object may have one or more data structures defined within the description of the object. Changes can be made to the data structures in a number of ways. Data field sizes can change, and the number of data fields can change. As with the state values, they should be considered in a very broad sense that is within the definition and the extent of the use of these data structures beyond local system usage. One must be aware that all syntactical changes in a technical definition need not be mandatory; they may be optional. Given that the changes are mandatory, they are most likely to affect every implementation, and are going to impact the functioning of the object. Such a case would warrant that the change be registered as a new technical object. EXAMPLE: A defined data field is changed from 3 octets to 4 and another field is reduced from 2 octets to 1 octet. Changing the data structure is probably the clearest case of a 13 PART 6 - REGISTRATION AUTHORITY PROCEDURES FOR THE OSE IMPLEMENTORS' WORKSHOP (OIW) December 1993 (Stable) requirement to change an implementation. One must be aware that all syntactical changes in technical definitions need not be mandatory, they may be optional. But if the changes are mandatory, they will most likely affect every implementation, and in such a way that they will not interoperate properly with old implementations. Such cases warrant that the change be registered as a new technical object with a new OID. With respect to applying these criteria, it should be emphasized that it is most important to be consistent in making subjective judgments concerning changes to registered technical objects, rather than being "correct." There may be more than one interpretation or "correct" view regarding any proposed change, but if the application of the guidelines are consistent, then the implementations are more likely to be consistent. C.3 The Change Process Responsibility for evaluating the change requests is assigned to each SIG. The SIG makes its determinations by voting on changes to each registered object as it is defined in the SIG text in the OIW Implementation Agreements Documents. Any SIG approved changes must also be voted in the OIW Plenary using the rules of the SIG and the Plenary. An object definition in a Working Agreement text is not registered until it has been voted into the Stable Agreements Document, so it is possible to modify an as yet "unregistered" object in the Working Agreements Document. 14