9.15 OPERATIONAL BINDINGS

Operational Binding is the term given to an operational relationship that may exist between a pair of DSAs. As we saw in Chapter 4, there can be many different sorts of operational relationships between DSAs, but so far, only three of these have been standardised. Operational relationships that are currently not standardised, will continue to have to be managed in a purely ad hoc, bilateral manner. Even the Operational Bindings that have been standardised may still need ad hoc bilateral agreements to be reached before they can be formally established between two DSAs. The standardised Operational Bindings do not have to be established via the Operational Binding management protocol (the DOP). Telephone calls or other proprietary means may equally well be used to manage the relationship. However, as the size and complexity of the Directory system grows, the automated DOP protocol will be found to have its benefits. The following description assumes that the DOP is being used to manage an operational relationship between a pair of DSAs.

All Operational Bindings, regardless of their type, have a common set of information that needs to be passed between the two co-operating DSAs. In addition, each specific type of Operational Binding will have its own special information requirements. Consequently, a generic Operational Binding protocol has been defined, in which certain parameters carry the common information, but in which other parameters have been left to be defined by the specific types of Operational Binding. The Operational Binding protocol (the DOP) consists of three (remote) operations: Establish Operational Binding (which activates the operational relationship), Modify Operational Binding (which modifies the parameters of the relationship) and Terminate Operational Binding (which kills the relationship between the two DSAs). There is also the DOP Bind operation, which is used to open up a connection between the two DSAs and to inform them that DOP operations are to follow, and the DOP Unbind operation, which is used to close the association after the DOP operations have been processed. The parameters of the DOP Bind and Unbind operations are exactly the same as those of the Directory Bind and Unbind operations described in § 5.2 and § 5.3 respectively.

9.16 ESTABLISHING OPERATIONAL BINDINGS

The parameters of the Establish Operational Binding Request and Result messages are listed in Tables 9.6 and 9.7.

If the DSA receiving the Establish Operational Binding Request message likes what it receives, then it will respond with an Establish Operational Binding Result message, and the relationship will be formally established. If the DSA receiving the Establish Operational Binding Request message does not like any of the parameters contained within it, then it responds with the Operational Binding Error message defined in the Standard, and no operational relationship will have been established.

The standardised Operational Binding Error message contains one of eleven pre-defined problem codes, and may optionally contain a revised set of parameters which constitute the Agreement. The eleven problem codes cover all conceivable types of problem, ranging from invalid start or finish time, through invalid or duplicate Operational Binding ID, to unsupported Operational Binding type. The reader should consult the Standard for the full list of problem codes.

Table 9.6 The parameters of Establish Operational Binding Request
Parameter ASN.1 Parameter Encoding Described in
Type of Operational Binding OBJECT IDENTIFIER 9.16.1
Operational Binding ID 
     identifier 
    version 		 SEQUENCE { 
     INTEGER, 
     INTEGER } OPTIONAL		 9.16.2 
 
Access Point of Initiator Access Point 9.16.3
Establishment Parameters Any OPTIONAL  9.16.4
The Agreement Any  9.16.5
Validity Time 
     Start 
     Finish 		 SEQUENCE { 
     UTC Time or Null, 
     UTC Time or Null }		 9.16.6 
 

Table 9.7 The parameters of Establish Operational Binding Result
Parameter  ASN.1 Parameter Encoding Described in
Type of Operational Binding  OBJECT IDENTIFIER 9.16.1
Operational Binding ID 
     identifier 
     version 		 SEQUENCE { 
     INTEGER, 
     INTEGER } OPTIONAL		 9.16.2
Access Point of Responder Access Point  9.16.3
Establishment Parameters Any OPTIONAL  9.16.4
 

9.16.1 Operational Binding Type

The Standard recognises that two fundamentally different sorts of Operational Binding may exist - symmetric and asymmetric ones. Symmetric Operational Bindings are relationships in which both of the DSAs essentially play the same role or roles, and neither DSA can be externally differentiated. The Standard has not yet formally identified any symmetric Operational Bindings in the global Directory, although the relationship between First Level DSAs may very well fall into this category. Asymmetric Operational Bindings, on the other hand, are relationships in which both DSAs have clearly defined roles, which are different. As described in Chapter 4, three types of Asymmetric Operational Binding have been standardised. Each type has been allocated an object identifier, which uniquely identifies it, as shown below:

2 5 19 1 - Shadow Operational Binding

2 5 19 2 - Hierarchical OperationalBinding

2 5 19 3 - Non-specific Hierarchical Operational Binding.

One of the above object identifier values is carried in the Establish Operational Binding message, in order to inform (or confirm to) the recipient DSA which type of Operational Binding is to be (or has been) established. Of course, it is perfectly possible for a community or users, or a DSA implementor, to define other types of Operational Binding, and to allocate object identifiers to these. Operational Bindings could then be created to manage the relationships between First Level DSAs, and DSAs with superior or cross references to each other etc. Currently there is no work underway in either ITU-T or ISO to standardise any of these.

9.16.2 Operational Binding ID

Since a pair of DSAs can participate in more than one Operational Binding of the same type (for example a subordinate DSA could hold two or more naming contexts subordinate to the one held in the superior DSA), then some sort of identifier is needed to differentiate between the two relationships. The Operational Binding identifier is used for this. The Operational Binding ID is always quoted when an Operational Binding is updated or terminated. The ID may initially be allocated by either of the two DSAs participating in the Operational Binding establishment, and it is a simple integer. In addition however, the identifier is qualified with a version number. This version number is set when the Operational Binding ID is first allocated, and is incremented each time the Operational Binding is updated (via the New Operational Binding ID parameter - see Table 9.8). In this way, both DSAs can always be sure that they are talking about the same version of a particular Operational Binding agreement.

9.16.3 Access Point

This is the access point of the DSA sending the Operational Binding message. It should be used by the receiving DSA next time it initiates any sort of communication with the sending DSA i.e. transmits a Bind operation (w/w 9.6). This parameter is the one that is used to update remote DSAs, when a DSA is re-configured to reside at a new address.

9.16.4 Establishment Parameters

The establishment parameters characterise each of the DSAs that are participating in the Operational Binding. The establishment parameters are therefore peculiar to the particular type of Operational Binding that is to be activated, and to the role of the DSA which is participating in the establishment of the binding.

For symmetric Operational Bindings, the establishment parameters will be the same for both DSAs - although each DSA may obviously insert different values for the parameters! Therefore the same set of parameters will be carried in both the establishment request and result messages.

Fig. 9.9 Establishing an Operational Binding.

For asymmetric Operational Bindings, the establishment parameters will be different for both of the DSAs entering the relationship. Each DSA will send its own role specific set of parameters in the Establish Operational Binding message exchange. If a DSA is sending the establishment request message, then its parameters will be included in the request message. If it is responding to the establishment request message, then its parameters will be sent in the result (Fig. 9.9). The establishment parameters for Shadow Operational Bindings are described in § 6.3.5. The establishment parameters for HOBs are described in § 9.20.2 and § 9.20.3.

9.16.5 The Agreement

The Agreement holds the set of parameters which characterise the particular relationship between the two DSAs. Thus each type of Operational Binding defines its own set of agreement parameters. The shadowing agreement parameters are described in § 6.3 (Table 6.1). The HOB agreement parameters are described in § 9.20.1 (Table 9.10). The agreement parameters are common to both DSAs. Therefore whichever DSA sends the establishment request message, sends the parameters of the agreement (Fig. 9.9). This gives the other DSA the opportunity either to accept or to reject the Operational Binding.

Some or all of the parameters of the Agreement may be updated via the Modify Operational Binding operation, and this is determined when the specific type of Operational Binding is defined. For example, the Shadow Operational Binding allows all the parameters of the Agreement to be updated except the base entry of the replicated area.

9.16.6 Validity Time

When the Operational Binding is first established, the initiating DSA proposes the validity time for the Agreement. This comprises two components, a start time and a finish time. Each component can either contain an absolute time in UTC format, or be null. (Null indicates now for the start time, and infinity for the finish time. Infinity in this respect means that the relationship will remain intact until it is explicitly terminated by either DSA.) The responding DSA can either accept the validity time as given or reject the establishment of the Operational Binding.

9.17 MODIFYING OPERATIONAL BINDINGS

Relationships between DSAs are necessarily dynamic. As a minimum, one could expect that the access point of a DSA might change when a system is re-configured. One of the problems experienced by '88 DSA administrators, is in updating all the remote DSAs that have knowledge references to their DSA. The Quipu implementation has solved this problem in an unnatural manner, by forcing DSAs to store their access points and their entries in a DSA higher in the DIT. Other implementations may use telephone calls or other proprietary means for propagating changes to access points. Help is now at hand in the '93 Standard, via the DOP Modify Operational Binding operation. It is now possible, for example, for a DSA to propagate a change of address via the DOP, prior to it actually taking place, and to inform the recipients of the start time for the new address. The full set of parameters available to the Modify Operational Binding Request are listed in Table 9.8. The Modify Operational Binding Result has no parameters (cf. the ModifyEntry operation - § 5.15.1).

A Modify Operational Binding Request is either accepted (via a null result message) or rejected (via the standardised Operational Binding Error message). If the modification request is rejected, then one of the eleven standardised problem codes is chosen for transmission, and optionally a revised set of agreement parameters may be suggested. Note that the agreement is never modified until a modification message, from one of the DSAs, has been accepted by the other DSA.

Whether or not a DSA is able to modify an Operational Binding, is determined at the time that the operational binding type is defined. It is possible to specify that neither, either or both DSAs may modify the Operational Binding. For all three currently standardised Operational Bindings, both DSAs are allowed to modify the parameters of the binding.

The Modify Operational Binding Request message can update any of: the access point of the initiating DSA, the modification parameters of the initiating DSA, and the parameters of the agreement. The choice is made when each specific type of Operational Binding is defined. The only mandatory parameters of the Modify Operational Binding Request are: the Operational Binding type identifier, the current Operational Binding ID (so that both DSAs confirm which version of the agreement is currently active, and is to be updated), and the new Operational Binding ID. The new version number of the ID must always be greater than the existing version number, so that old versions of the agreement cannot be re-activated. (This is not to say that the same old parameters cannot be used again, only that a new version number must be allocated to them each time around.) If the modify is successful, then the new version of the Operational Binding will come into effect at the new start time, and the current version will cease to be valid. If the modify is unsuccessful, then the current version of the binding remains valid.

Table 9.8 The Parameters of Modify Operational Binding Request
Parameter ASN.1 Parameter Encoding Described in
Type of Operational Binding OBJECT IDENTIFIER 9.16.1
Operational Binding ID 
     identifier 
     version 		 SEQUENCE { 
     INTEGER 
     INTEGER}		 9.16.2 
Access Point of Initiator Access Point OPTIONAL 9.16.3
Modification Parameters Any OPTIONAL 9.17.1
New Operational Binding ID  Operational Binding ID 9.16.2
New Agreement Any OPTIONAL 9.16.5
Validity Time 
     Start 
     Finish 		 SEQUENCE { 
     UTC Time or Null, 
     UTC Time or Null } OPTIONAL		 9.16.6

9.17.1 Modification Parameters

The modification parameters are used to update the information that is associated with one of the DSAs in the relationship. For asymmetric Operational Bindings, the modification parameters will be different for each DSA. For symmetric Operational Bindings, the parameters will be the same.

The role that each DSA can play in the establishment, modification and termination of the Operational Binding is partly specified via the role specific establishment, modification and termination parameters. Often the modification parameters are a subset of the establishment parameters, and indicate which of the establishment parameters can be updated e.g. this is true for HOBs, see § 9.21. This is not always the case though. For example, a shadow consumer DSA has a role to play in modifying some parameters of the shadowing relationship, that do not exist when the agreement is first established. This is to tell the supplier DSA about any secondary shadows that it subsequently supplies (clearly these cannot exist when the shadowing agreement is first established). As a consequence, the modification parameter Secondary Shadows is defined for the shadow consumer (§ 6.4.2), but no equivalent establishment parameter is defined.

Whenever a DSA wishes to update its modification parameter via the DOP, it must initiate a Modify Operational Binding operation.

9.18 TERMINATING OPERATIONAL BINDINGS

Terminating an Operational Binding destroys the operational relationship between the two DSAs. The termination may be pre-scheduled, for example, a DSA may contract to shadow a portion of the DIT from another DSA, for a finite duration. If the DOP is used to manage this relationship, then the validity time parameter of the Establish Operational Binding Request can be set to the pre-determined finish time. Alternatively, the termination may come as a direct result of a change of administrative policy, or because of a violation of the agreement by one of the DSAs. If the DOP is used to manage this relationship, then one of the DSAs issues a Terminate Operational Binding Request.

When the Operational Binding type is defined, it is specified which of the two DSAs may terminate the agreement. It is possible to specify that neither, either or both DSAs may terminate an Operational Binding. For all three currently standardised Operational Bindings, both DSAs are allowed to terminate the binding. The parameters of the Terminate Operational Binding Request are given in Table 9.9. The termination response message carries no parameters.

When terminating an Operational Binding, only the identifier, and not the version number, of the Operational Binding ID needs to be quoted, since it is immaterial which version of the agreement is being terminated.

Termination parameters are defined during the definition of the Operational Binding type. Separate termination parameters can be defined for each of the DSA roles. However, none of the three standardised Operational Bindings defines any termination parameters, and it is hard to see when they might be useful.

If the termination time parameter is absent, then termination is immediate, otherwise termination will take place at the specified time.

A properly formulated Terminate Operational Binding Request message is always successful - no error message problem code is defined to allow a refusal. Of course error codes are defined for rejecting incorrectly formulated termination request messages, such as those with a wrong Operational Binding ID, which do not identify any currently active Operational Bindings. But generally speaking the recipient DSA cannot refuse to terminate an active relationship. If, in an extreme case, the recipient DSA refuses to reply to a termination request message, then the calling DSA can always unilaterally remove all knowledge of the Operational Binding ID, thereby effectively terminating the agreement without the remote DSA being involved.

Table 9.9 The parameters of Terminate Operational Binding Request
Parameter ASN.1 Parameter Encoding Described in
Type of Operational Binding  OBJECT IDENTIFIER 9.16.1
Operational Binding ID 
identifier		 SEQUENCE { 
INTEGER } 		 9.18
Termination Parameters Any OPTIONAL 9.18
Termination Time UTC Time OPTIONAL 9.18

9.19 HIERARCHICAL OPERATIONAL BINDINGS

A Hierarchical Operational Binding, or HOB for short, describes the relationship that exists between a pair of DSAs that hold adjacent naming contexts. The superior DSA holds a subordinate reference to the subordinate DSA, and the subordinate DSA holds an immediate superior reference to the superior DSA. Non-specific Hierarchical Operational Bindings, or NHOBs, are similar to HOBs, only in this case the superior DSA holds a NSSR to the subordinate DSA. Since NSSRs are similar to, but much less important than subordinate references, HOBs rather than NHOBs will be described.

The parameters of the HOB are the minimum that are required in order for the distributed Directory to function as described in the Standard. The parameters are not necessarily sufficient for a real pair of DSAs to inter-operate in the commercial world, since issues such as tariffs and quality of service are not addressed. However, this is because these issues are outside the scope of the '93 Standard.

The HOB carries sufficient parameters between the pair of DSAs, in order to allow:

HOBs are absolutely essential if the distributed Directory is to function as intended, and they already implicitly exist in deployed '88 implementations. What the '93 Standard has done, is to formalise these hierarchical relationships, by parameterising the information that flows between the DSAs, and by standardising a protocol that may be used to carry this information. '88 DSAs have to use their own ad hoc means for establishing and maintaining their HOBs, which probably means that phone calls, Email or other proprietary means are used to transfer the information.

9.20 ESTABLISHING THE HOB

HOBs may be managed via the generic Operational Binding messages described in § 9.15. Either the subordinate or the superior DSA may establish the HOB. HOB establishment may arise automatically, as a result of an AddEntry request which specifies that the entry be added to a different DSA from that of the parent entry (§ 5.13.3), or it may arise due to administrative action, for example, when the administrator of the subordinate DSA wishes to hook its naming context into the global DIT (§ 9.9). The HOB specific Operational Binding parameters used in the Establish message are listed in Tables 9.10, 9.11 and 9.12.

9.20.1 The Parameters of the Hierarchical Agreement

The HOB agreement is very simple. It consists of two parameters which serve to link the two DSA together hierarchically. These are: the RDN of the naming context in the subordinate DSA, and the distinguished name of the parent entry in the superior DSA. If the HOB is initiated by the superior DSA, as a result of an AddEntry operation, then the RDN will be that of the new entry to be added to the DIT. If the HOB is initiated by the subordinate DSA, the subordinate DSA is stating whereabouts in the DIT (the immediate superior) it wishes its existing naming context to be connected to.

Table 9.10 The parameters of the Hierarchical Agreement
Agreement Parameter ASN.1 Parameter Encoding
Subordinate RDN Relative Distinguished Name
Immediate Superior Distinguished Name
 

Table 9.11 The parameters of the superior DSA
Superior Parameter ASN.1 Parameter Encoding
Context Prefix Information 
     RDN 
     Admin Point Info 
     Subentry Info 
 
     Access Points 		 SEQUENCE of SEQUENCE { 
     Relative Distinguished Name, 
     SET of Attributes OPTIONAL, 
     SET of { RDN, 
          SET of Attributes} OPTIONAL, 
     Master And Shadow Access Points OPTIONAL }
Entry Information  SET of Attributes OPTIONAL
Immediate Superior Info  SET of Attributes OPTIONAL
 

9.20.2 The Superior DSA Role Specific Establishment Parameters

The Superior Parameters contain information which the superior DSA needs to pass to the subordinate DSA. They may consist of administrative information, an immediate superior reference, the attributes of the new subordinate (context prefix) entry, and some attributes from the parent entry.

The Context Prefix Information enables the superior DSA to pass to the subordinate DSA all of the administrative information that governs the subordinate naming context. The Context Prefix Information holds the RDNs of all of the superiors of the subordinate naming context, starting with the RDN of the First Level DSE, and ending with the RDN of the parent of the subordinate naming context. If the subordinate naming context is part of an administrative area which starts at an administrative point held in the superior DSA, then the appropriate administrative information (Admin Point Info) is packaged along with the RDN of the administrative entry. Any subentries (Subentry Info), that govern entries within the subordinate naming context, are also packaged along with the administrative entry information. In this way, the subordinate DSA gets a copy of all of the administrative entries and subentries that control entries within its naming context. If the subordinate naming context represents the start of a new Autonomous Administrative Area, then the Admin Point Info and Subentry Info will always be absent.

The Context Prefix Information also passes to the subordinate DSA one or more immediate superior references (Access Points). These are included in along with the RDN which represents the relative distinguished name of the naming context held by the superior DSA. The superior DSA passes a list of all of the DSAs (Master and Shadow Access Points) which have (commonly usable) copies of the immediately superior naming context. In this way redundancy may be built into name resolution (going up the DIT). Note that the list does not have to be complete if security or other reasons forbid it.

Entry Information is an optional parameter that holds the attributes of the new entry to be added as a subordinate naming context. This parameter will only be present if the superior DSA initiates the Establish Operational Binding Request message, as a result of an AddEntry request.

Immediate Superior Info is only optionally present when the two DSAs share the same access control specific administrative area. It holds the ACI for the parent entry of the subordinate naming context. This can be used by the subordinate DSA when evaluating a List request of the parent entry, in order not to give away information that the user is not entitled to see.

At its minimum, the superior DSA's role specific parameters will consist of simply a list of RDNs containing an embedded master access point, i.e. an immediate superior reference for the subordinate DSA.

9.20.3 The Subordinate DSA Role Specific Establishment Parameters

The Subordinate Parameters contain information which the subordinate DSA needs to pass to the superior DSA. They consist of a subordinate reference, and information about the root (context prefix) entry of the subordinate naming context.

The Access Points parameter holds a list of all of the DSAs that have a (commonly usable) copy of the subordinate naming context. This will be used to create a set of subordinate references by the superior DSA. In this way redundancy is built into name resolution, going down the DIT. Note that the list may not be complete if security or other considerations dictate so.

The Alias Flag is used to signal if the subordinate naming context consists of a single alias entry.

The Entry Information parameter may optionally contain the access control attributes for the context prefix entry. These parameters may subsequently be used by the superior DSA to optimise the evaluation of a List request whose target object is the parent entry of the subordinate naming context.

9.21 MODIFYING THE HOB

All the parameters of the HOB may be updated, both the agreement parameters and the role specific parameters, except that the superior DSA may not update the Entry Information parameter, since this is achieved via a normal ModifyEntry operation.

Table 9.12 The parameters of the subordinate DSA
Subordinate Parameter ASN.1 Parameter Encoding
Access Points Master And Shadow Access Points
Alias Flag BOOLEAN DEFAULT FALSE
Entry Information SET of Attributes OPTIONAL
 

The role specific parameters are updated whenever either DSA changes its Access Point, or when administrative information in the superior DSA is updated, or when another shadow copy of either naming context is created or deleted, or when the access control information in either the context prefix entry or its parent changes. For example, if either the subordinate or the superior DSA subsequently copy their naming context to another DSA, then they can modify the HOB information, by updating the Master and Shadow Access Points parameter that they passed as an establishment parameter. Alternatively, if the administrative information in the superior DSA is updated then this information is propagated to the subordinate DSA via a new value for the Context Prefix Information. For example, prescriptive access controls, held in a subentry in the superior DSA, but which control part of the subordinate naming context, may be updated, or a new collective attribute may be added to a subentry in the superior DSA. Even if the DOP is not supported, this information will still need to be propagated to the subordinate DSA by proprietary means, otherwise the information in the global DIT would be inconsistent.

The agreement parameters are updated whenever the RDN of the context prefix entry, or one of its superiors, is updated. The '93 ModifyDN operation permits the RDN of any entry to be changed. If the context prefix entry is renamed, then the subordinate DSA will initiate the HOB modification, and will pass the new subordinate RDN value to the superior DSA. If an entry superior to the context prefix entry is renamed, then the superior DSA will initiate the HOB modification, and will update the Immediate Superior parameter. Each entry below the one whose RDN is updated, will need to have its distinguished name changed to reflect the change higher up in the DIT. Several HOBs may thus be affected by a single RDN change - imagine the changes that would be necessary if a country changed its name. Not only may there by several naming contexts immediately subordinate to a single entry, but each naming context may have other naming contexts subordinate to it. We may thus have a cascading effect of one DIT change affecting many HOBs, e.g. see Fig. 4.7. A similar effect will be observed when administrative information, which covers a large administrative area that is distributed between many DSAs, is updated. HOB updates will need to be linked together so that, where appropriate, changes may be rippled to the leaves of the DIT.

9.22 TERMINATING A HOB

Terminating a HOB has the primary effect of isolating the subordinate naming context (and any naming contexts subordinate to it) from the global DIT. As far as the superior DSA (and the rest of the world) is concerned, the subordinate entry ceases to exist. It is not known about nor contactable, since the parent entry no longer has a subordinate reference to it. (A different entry of the same name, could therefore legitimately be created in another DSA. A few other DSAs may still have cross references to the disconnected subordinate naming context, but this does not keep it fully inter-connected to the global DIT.) Either DSA may initiate the termination (§ 9.18).

The subordinate naming context may not actually cease to exist. It would be up to the administrator of the subordinate DSA, to decide whether or not to delete the naming context. It may be that the policy of the organisation was to remove itself from the global DIT, and to exist as a private closed domain. On the other hand, the HOB termination may be as a direct result of a RemoveEntry operation (or similar administrative action), in which case it was intended to delete the subordinate naming context. In either case the subordinate DSA would initiate the termination.

Termination by the superior DSA may only result from administrative intervention, and not from a Directory operation.

9.23 CONCLUSION

You may now appreciate that the operation of the distributed Directory is relatively complex. Whilst the technical implications of a distributed Directory have now largely been solved (and any bugs remaining will normally be fixed by the defect mechanism), it is the more difficult operational issues that are still to be worked out. When security, privacy and financial aspects are of minimum importance, then a distributed Directory pilot service can quickly be established, as is shown by the US White Pages and EC Paradise pilots. When commercial and security issues are of maximum importance, then the distributed Directory takes much longer to implement. The NADF have been working at this for several years, and by the end of 1993 still did not have a pilot service to offer.

WEIRD AND WONDERFUL

9.1 The debate about whether a knowledge reference points to just one or to many DSAs continued for a long time. Since replication was not supported in the '88 edition of the Standard, there typically would only be one DSA holding a particular naming context, and so there could not be more than one DSA associated with a particular context prefix. However, in the case of NSSRs, where the name of the subordinate entry was not known, there might be several DSAs holding the many children of an entry (and thus be associated with the wildcard name). And when replication was supported in '93, again, there could be many DSAs holding copies of the same naming context. So should a knowledge reference have a set of access points associated with the DIT name that it points to? It was finally decided that a knowledge reference only points to a single DSA. However, a specific knowledge attribute held in a DSA Information Tree points to a set of DSAs. It thus holds a set of knowledge references. Unfortunately, the Standard does not define a term - a collective noun - for a set of knowledge references that all point to copies of the same subtree.

9.2 The rationale for introducing non-specific subordinate references has now been lost in the midst of time. The author recollects that a deregulated PTT did not want to have to divulge its customers to a competitor, and so wanted to have NSSRs in the Standard. They fought very strongly to have this feature included. No such requirement now seems to exist, and there have been several attempts since 1988 to remove NSSRs from the Standard, but failing that, from the root context. All such attempts to date have so far failed, the argument being used is one of compatibility with the '88 version of the Standard. So we have a feature that significantly complicates several aspects of the distributed operation of the Directory, that no longer has a rationale for existence, but cannot be removed because of compatibility with a previous version of the Standard! Note that all the functional standards groups have banned NSSRs from being present in the root context, and the NADF has banned them from being present in the entire North American shared user friendly naming tree.

9.3 Most knowledge reference attributes have redundancy built into them, since they point to both master and shadow DSAs that hold copies of the same naming context. The root context has redundancy built into it, since the subordinate references of the root, held by First Level DSAs, point to the master and shadow copies of the First Level entries. Unfortunately redundancy has not been completely built into non-First Level DSAs, since they only have one access point allowed in their superior knowledge attribute. This attribute really should have multiple values, so that it can point to several superior DSAs. I am sure that operational managers will want to have a backup superior DSA. Maybe someone should fix this. Quipu certainly allows it!

9.4 The presence of the second parameter (aliasedRDNs) in Chaining Arguments, concerning alias dereferencing, obviates the need for the first parameter (Alias Dereferenced). A positive value of the former implies True for the latter, since one cannot have a count of the number of RDNs that have come from an alias if an alias has not been dereferenced. Similarly, a null, or zero, value of the former implies False for the latter. This duplication of signalling was noted by at least one expert, and so Referrals only contain the Aliased RDNs field, although Chaining Arguments still managed to retain both!

9.5 One of the rationales for supporting replication in the Directory, is that performance should improve. The fact that many DSAs can hold copies of the same subtrees, led to the surprising result that for a Search Whole Subtree operation, performance can actually be degraded in the presence of replication! This is because each DSA subordinate to one in which the search starts, may process the whole search, and produce duplicate results. This could never happen in an '88 DSA which only ever held master entries. As an example, consider a modified Fig. 9.7, in which DSAs 2, 3, 4 and 5 each hold complete copies of all of the subordinate naming contexts of DSA1. If DSA1 undertakes parallel multi-chaining to all of its subordinate DSAs, duplicate results will be produced by each one of them, and the operation will take longer to perform than would be the case if replication was not supported.

9.6 How many access points does a DSA have? It could have several, for example, a different one for each protocol (application context) that it supports i.e. DOP, DSP, DAP, DISP. This was discussed at the ISO/CCITT meetings, and it was decided that is was preferable for a DSA to have only one access point, and that the application context in the Bind message should be used to switch between protocols. For this reason the Establish and Modify Operational Binding protocol messages only carry one access point, and this is the access point that is to be used for all future communications with the DSA.