[Css-csts] Inconsistencies in UNBIND behavior

[Yves.Doat at esa.int]

Dear John,
Thank you for your comment.
In the release 0.12 the association was not yet consolidated and I did not 
update the state table. I considered your comments and updated the table 
as follows:

IF “positive result”
THEN (+unbindReturn)
    {unbind}
    {clean up}
-> 1
ELSE (-unbindReturn) 
-> 2.1

This presentation is in line with the rest of the table. Please let me 
know if you agree.

Best regards

Yves
__________________________________________________
Head Ground Infrastructure Baseband Section (OPS-GIB)
ESA/ESOC Robert-Bosch Strasse 5
D-64293 Darmstadt, Germany
Tel.: +49 (6151) 90.2288               Fax:+49 (6151) 90.3046
Internet: http://www.esa.int/
__________________________________________________




"John Pietras" <john.pietras at gst.com> 
Sent by: css-csts-bounces at mailman.ccsds.org
22/01/2008 21:38

To
<css-csts at mailman.ccsds.org>
cc

Subject
[Css-csts] Inconsistencies in UNBIND behavior






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_______________________________________________
Css-csts mailing list
Css-csts at mailman.ccsds.org
http://mailman.ccsds.org/cgi-bin/mailman/listinfo/css-csts


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