[Css-csts] Inconsistencies in UNBIND behavior

[John Pietras]

Members of the CSTSWG ---
There seem to be inconsistencies between the way that the UNBIND
operation is defined and the way that it is subsequently used in the
various procedures, at least as documented in the 0.11 version of the
Procedures Definition specification.
Under the UNBIND operation definition (section 4.6), section 4.6.2.2.1
states "If the result is 'negative result' and none of the diagnostic
defined in 4.4.2.7 is suitable, the diagnostic parameter may be used by
specific transfer services or specialized procedures to convey
additional information."
and section 4.6.2.3 states:
"The unbind-reason shall take one of the following values::
	a) 'end'-the user has performed all expected activities and is
releasing the association normally: the provider may delete the service
instance and release all its resources associated with it; 
		NOTE - If unbind-reason is 'end', any subsequent attempt
to invoke BIND will fail even if the service instance provision period
has not expired, since the service provider may release the resources
allocated to that service instance. 
			b) 'suspend'-the user is suspending usage of
this service instance for an unspecified period of time; the user may or
may not re-bind to the provider to continue data transfer at some time
prior to the end of the service instance provision period; 
	c) 'version not supported'-the user does not support the version
of the service proposed by the provider in the return from BIND: this
value of unbind-reason shall be used only if the UNBIND is the first
operation invoked following the BIND; 
	d) 'other reason'-the reason for the release will have to be
found by other means."

In the Association Control procedure definition section (5.4), the state
table for the Association Control procedure (table 5-3) specifies the
behavior in response to an UNBIND invocation of a procedure instance in
the 'bound'/'ready state' as:
		(+UnbindReturn)
		-> 1
		IF "end"
		THEN
			{unbind}
			{clean up}
		ELSE [ignore] 
	
There seem to be several problems with this behavior. 

First, it does not allow the possibility of a negative result
(-UnbindReturn), although the definition of the UNBIND clearly supports
such a possibility. 

Second, by this definition, the compound action {unbind} only occurs
when "end" is the unbind-reason. This is not a very good name for the
compound action, because a reader would naturally assume that an action
called {unbind} will always occur as part of a successful UNBIND
operation. Perhaps a name like {end service instance} could be used.

Third, shouldn't some or all of the actions that comprise the {clean up}
compound action occur for the other unbind-reasons as well? I'm thinking
in particular about the various timers - aren't they suspended whenever
the service instance is unbound? 

Finally, the sequence of actions seems out of place; i.e., the state
transitions to state 1 and then {unbind} (or {end service instance}) and
{clean up} occur (if unbind-reason = "end"), otherwise something is to
be ignored. The UNBIND invocation itself should be ignored if it is
invalid, but as currently written this is not a possibility. On the
other hand, maybe the ELSE is simply intended to say "don't do anything
else beside going to state 1 if the bind-reason is not 'end'", but in
that case [ignore] seems to be the wrong action.

If we then look at the Buffered Data Delivery procedure(5.6), the
behavior of a procedure instance in response to an 'unbind' event is
defined in all cases as {clean up}, regardless of the unbind-reason. Is
this the correct behavior, or should the behavior of the non-Association
Control procedures also be governed by the unbind-reason?

Best regards, 
John

John Pietras
Global Science & Technology, Inc. (GST)
7855 Walker Drive
Suite 200
Greenbelt, Maryland, USA
20770-3239
Direct:   +1-240-542-1155
GST Main: +1-301-474-9696
Fax:      +1-301-474-5970

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/css-csts/attachments/20080122/778a9d8c/attachment.htm