home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Standards
/
CD1.mdf
/
nist
/
oiw
/
agreemnt
/
1993
/
06s_9312.txt
< prev
next >
Wrap
Text File
|
1994-02-13
|
36KB
|
1,254 lines
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
