[Css-csts] Re: response to BIND invocation when already bound
Yves.Doat at esa.int
Yves.Doat at esa.int
Fri Jan 23 10:23:37 EST 2009
Dear John,
You are right. Your note is confirmed by the MoM from our teleconference
100805 section "7. Guidelines" that state:
In case a BIND is received and the service is already bound, the service
should send back an error ‘already bound’ rather than aborting (this approach
is required to be in line with SLE).
Note: The MoM can be found on the CWE: CSS-CSTS/Meeting Materials/2008 Spring
teleconferences.
I will update the Recommendation accordingly.
Regards
Yves
"John Pietras"
<john.pietras at gst.
com> To
<Yves.Doat at esa.int>
23/01/2009 15:55 cc
<css-csts at mailman.ccsds.org>
Subject
response to BIND invocation when
already bound
Yves,
After yesterday’s telecon, I continued to update the Guidelines. I came
across a note from our conversation last summer regarding the action in
response a BIND invocation when the service state is ‘bound’. What I had in
the Guidelines was
{peer abort ‘protocol error’}
{clean up} -> 1
Hand-written near this is the note “(-BindReturn) ‘already bound’”.
We had apparently discussed the fact that the BIND diagnostic ‘already bound’
is intended to be used in this case, despite of the more-general rule of
always aborting whenever a PDU is received that is not allowed for the state.
As I recall, you pointed out that this was kept in the Toolkit version of the
BIND operation to be consistent with the SLE BIND operations.
I raise this point because the same thing occurs in the Association Control
Service Provider State Table (Table 4-2) of the R-0.17 Framework. In that
table, the state 2 (‘bound’) entry for the (BindInvocation) incoming event is
{peer abort ‘xxx’}. To be consistent with our discussion of last summer, this
should be (-BindReturn).
Best regards,
John
More information about the Css-csts
mailing list