[Css-dts] Clarification of how initiatorIdentifier and ResponderIdentifier parameter values are assigned

John Pietras john.pietras at gst.com
Thu Sep 30 16:19:37 EDT 2004


Members of the DTSWG,
In the most-recent draft versions of the transfer service specifications
that I have available to me (August 2004), there is a difference in
sections 3.1.4.2 and 3.1.4.3 between the forward (CLTU and FSP) and
return (RAF, RCF, and ROCF) books. The sections in the forward books
are:
"3.1.4.2 The initiator shall have access to a registry of authorized
responders and the responder shall have access to a registry of
authorized initiators. These registries shall be maintained by SLE
Complex Management and SLE Utilization Management, respectively.
3.1.4.3 Service management shall specify the authorized initiator and
responder for each service instance."

The sections in the return books are similar to the following excerpt
from the ROCF book:
"3.1.4.2	When processing an ROCF-BIND invocation, the responder
shall verify that the initiator, as indicated by the
initiator-identifier parameter of the invocation, is the authorized
initiator for this service instance; if not, the responder shall not
perform the ROCF-BIND and shall return a 'negative result' to the
initiator.
3.1.4.3	When processing the return from ROCF-BIND, the initiator shall
verify that the responder, as indicated by the responder-identifier
parameter of the return, is the authorized responder for this service
instance; if not, the initiator shall abnormally terminate the
association by invoking ROCF-PEER-ABORT."

Is this an intentional distinction between forward and return SLE
transfer services, or simply an artifact of two different ancestor
documents?

I am having difficulty interpreting the two sections that are written
for the forward books. Does "Service Management" (in the form of UM, the
service management element usually associated with initiator) configure
the initiator process with specific initiatorIdentifier and
responderIdentifier values prior to the BIND, or does UM configure the
initiator only with the initiatorIdentifier and allow the initiator to
select the responderIdentifier from the registry?

If UM configures the initiator process with specific initiatorIdentifier
and responderIdentifier values, does this do this in coordination with
CM (the responder's service management entity), in which case CM would
pre-configure the responder with the same specific initiatorIdentifier
and responderIdentifier pair of values? Or does UM merely configure the
responder with the responderIdentifier, and the responder just waits to
see what initiatorIdentifier shows up in the BIND invocation and check
the registry at BIND time to see if the initiatorIdentifier is valid for
that responderIdentifier?

The answers to these questions will affect the way Service Management
operates, and also how Annex F of the Cross Support Concept Green Book
will be rewritten.

Thanks in advance for your help.

Best regards,
John



More information about the CSS-dts mailing list