[Css-csts] Accommodating 3-phase operations

[John Pietras]

Yves,
Thank you for your response. I will proceed along the path that you have
suggested - that is, to define different diagnostics for each response.

However, your reason for not allowing the value of the result parameter
to be constrained has made me curious. You stated that the WG determined
that "any information defined at the level of the common hear is
available to all operations. One cannot descope part of the information
defined there." This seems to be a departure from the general concept of
refinement. Are only the standard headers exempt from refinement, or are
there other rules or limitations on when refinement can be used?

By the way, it may not be important enough to make the change (or it may
be too late), but I will mention that in the SMWG we have discussed that
the names "2-phase" and "3-phase" are perhaps not the best names, and if
we were to start again we would probably name the 3-phase operation
"acknowledged" operation instead. I don't know if we are seriously
considering this change for SLE-SM, but I offer it as a thought for the
CSTSWG while the Toolkit material is still being developed (the 3
operation types could be "unconfirmed", "confirmed", and "acknowledged"
[where "acknowledged" is the special (2-return) case of "confirmed"]).

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

> -----Original Message-----
> From: Yves.Doat at esa.int [mailto:Yves.Doat at esa.int]
> Sent: Tuesday, December 05, 2006 3:20 AM
> To: John Pietras
> Cc: css-csts at mailman.ccsds.org; css-csts-bounces at mailman.ccsds.org
> Subject: RE: [Css-csts] Accommodating 3-phase operations
> 
> 
> Dear John,
> I finally found a little bit of time for preparing an answer to your
mail
> with my understanding. For my reasoning I add at the beginning some
> history
> and constraints that I listed to help me to come to my answer at the
> bottom
> of the mail.
> 
> THROW-EVENT PROCEDURE
> That procedure is derived from the needs to execute directive that
affect
> the
> complex management. The execution of such directives may take a
certain
> time
> (predictable or unpredictable). The reason of having a
3-phases-operation
> is
> to ensure that not only the acknowledgement of the reception is
provided,
> but
> also the acknowledgement of the processing results of the directive.
The
> processing may end with a positive or a negative result.
> 
> 
> APPROACH IN THE DRAFT BOOK AND PROCEDURES:
> We have two types of common headers: confirmed header operations and
> unconfirmed header operation. In the context of the
3-phases-operation, we
> are only concerned with the confirmed header operation.
> 
> All confirmed operations use the confirmed header operation.
> This implies that all confirmed operations can have a positive or
negative
> answer and we shall not restrict that possibility.
> In case of positive answer, the answer may carry additional
information.
> In case of negative answer, the answer carries a diagnostic (one of
the
> common diagnostics or one of the extended diagnostics) and possibly
> additional information.
> From the approach discussed in the WG one cannot exclude negative
answers
> to
> a confirmed operation. During the discussions we were very clear that
any
> information defined at the level of the common hear is available to
all
> operations. One cannot descope part of the information defined there.
> 
> 
> 3-PHASES-OPERATION
> In the 3-phases-operation each answer can be positive or negative.
> 
> The first answer may be positive or negative.
> If the first answer is positive:
> - the answer may carry additional information;
> - a second answer is to be expected.
> If the first answer is negative:
> - one of the standard diagnostics is to be used;
> - alternatively an extended diagnostic is to be used;
> - the answer may carry additional information;
> - a second answer is not to be expected.
> 
> The second answer may be positive or negative.
> If the second answer is positive:
> - the answer may carry additional information.
> If the second answer is negative:
> - one of the standard diagnostics is to be used
>    formally speaking, the second answer could carry the diagnostic
> 'duplicate-invoke-id',
>    the 'out-of-service' diagnostic could occur if between sending the
> first
> and the second answer, the provider becomes out-of-service,
> - alternatively an extended diagnostic is to be used;
> - the answer may carry additional information.
> 
> As you can see from the above description and due to the inheritance
of
> the
> common header it is not possible to enforce a positive response.
> 
> 
> YOUR QUESTION: How to handle diagnostics between the two answers?
> The question you are raising: do we have to use the same diagnostics
for
> both
> answers or can we have distinct diagnostics is valid. We should look
into
> the
> possibility to have two diagnostic extensions: one set for the first
> answer
> and one set for the second answer. I propose you work-out the
procedure in
> that direction identifying the diagnostics for the first and second
> answers.
> We will then check for consistency with the rest of the document.
> 
> Best regards
> 
> Yves DOAT
> __________________________________________________
> 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>
> To
>              Sent by:                   Yves.Doat at esa.int
>              css-csts-bounces at m
> cc
>              ailman.ccsds.org           css-csts-
> bounces at mailman.ccsds.org,
>                                         css-csts at mailman.ccsds.org
> 
> Subject
>              17/11/2006 22:47           RE: [Css-csts] Accommodating
3-
> phase
>                                         operations
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Yves and members of the CSTSWG,
> Your proposal to add a parameter (confirmation) outside of the
standard
> header to signal the acknowledgement vs. final return status, raises
> issues
> that I have not yet seen addressed in the CSTSWG documentation.
> 
> Under your proposal, the acknowledge return could have either a
> 'positive-result' or 'negative-result' value for the result parameter.
> Does
> it even make sense to have a "negative acknowledgement"? The answer to
> this
> question may depend on what the acknowledge return is truly supposed
to
> represent. I have read CCR 44 (which establishes the 3-phase
operation)
> and I
> do not understand the complete significance that is intended for the
> acknowledge return. Using SLE-SM for comparison, the SLE-SM
acknowledge
> return signals 3 pieces of information:
> 1) the performer has received the invocation,
> 2) the invocation is validly formatted and conforms to the protocol
for
> that
> operation, and
> 3) the final disposition can be expected no later than the time
specified
> in
> the return.
> 
> For CSTS services, I think we can rule out item (3) above, because
CSTS
> operations should complete on the order of a minute at the latest,
> compared
> with SLE-SM operations (e.g., scheduling a space link) which might not
be
> completed for days, weeks, or even months.
> 
> That leaves us with items (1) and (2). If the acknowledgement merely
> confirms
> receipt of the invocation, then a subsequent negative-result can have
a
> diagnostic with any of its defined values. On the other hand, if an
> acknowledgement is supposed to signify that some level of validation
has
> been
> passed (e.g., that the invoke-ID is not a duplicate, that the service
> provider is in-service), then a subsequent final return with a
negative
> result should *not* have diagnostic values that indicate otherwise
(e.g.,
> that the invoke-ID is a duplicate or that the provider is out of
service)
> since the preceding acknowledgement has implied otherwise.
> 
> I can think of two ways of addressing this issue (there are probably
more
> ways, but I will put these two on the table to initiate the
discussion).
> 
> The first approach would be to use the positive acknowledgement (that
is,
> a
> return with the combination of result= positive-result' and
confirmation =
> 'acknowledge'(or 'initial' or 'first')) to signal successful
validation of
> all of the associated tests (whatever we define those to be), and the
> negative acknowledgement (result = negative-result' and confirmation =
> 'acknowledge') to signal failure of one of those tests. Use of this
> approach
> would require that the specification of the 3-phase operation and/or
the
> procedures that use that operation specify which diagnostic values are
> permitted in the negative acknowledgement, and which are permitted in
> negative final resolution (that is, a return with the combination of
> result=
> negative-result' and confirmation = 'final'(or 'second')). [Note that
this
> is
> equivalent to what's done in SLE-SM, where if the validation checks
> leading
> to an acknowledgement fail, an invalidMessageResponse is sent].
> 
> The second approach would be to constrain the value of the result in
the
> acknowledge return to always be result= positive-result, but allow a
> single
> negative final disposition to be sent instead of an acknowledge return
if
> the
> failure occurs in the validation leading to the acknowledgement. This
> approach does not require the set of diagnostic values to be
partitioned
> into
> pre- and post-acknowledgement categories.
> 
> Perhaps these distinctions are addressed and resolved in material that
I
> have
> overlooked, or have been resolved in a CSTSWG session that I did not
> attend.
> If so, please accept my apologies. But if this is still an open issue,
I
> believe that we need to decide between these two approaches and
possibly
> other variations.
> 
> 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
> 
> 
> From: Yves.Doat at esa.int [mailto:Yves.Doat at esa.int]
> Sent: Thursday, November 16, 2006 5:12 PM
> To: John Pietras
> Cc: css-csts at mailman.ccsds.org; css-csts-bounces at mailman.ccsds.org
> Subject: Re: [Css-csts] Accommodating 3-phase operations
> 
> 
> Dear John
> 
> If we look at the individual parameters of the standard header, we
see:
>    1. performer-credential: not suitable to carry the information;
>    2. invoker-id: the values of the invocation and the two returns are
the
>       same;
>    3. Result can be positive or negative result. The information
> associated
>       to a positive result will be carried by the parameter
>       positive-result-return. The information associated to a negative
> result
>       will be carried by the parameter diagnostic.
> So obviously we do not have a dedicated field for that information and
> this
> information cannot be carried by the standard header.
> 
> As you know all the approach is based on the extension capability of
the
> operations, of the procedures and of the service. I propose therefore
that
> the DIRECTIVE operation is defined with:
> 
>         Parameters                                       Invocation
> Return
> standard-operation-header (confirmed)                        M
> M
> confirmation
M
> ....
> extension-parameter                                        M
M
> 
> 
> In the returns the confirmation parameter would take the values
> first/second
> responses or initial/final responses
> I hope this answer your question. Please let me know if you agree with
my
> answer.
> 
> Best regards
> 
> Yves DOAT
> __________________________________________________
> 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
> To
>
css-csts at mailman.ccsds.org
> 
> cc
>  14/11/2006 16:15
> 
> Subject
>                                               [Css-csts] Accommodating
>                                               3-phase operations
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Members of the CSTSWG:
> CCR-44 identifies the need for 3-phase operations, and suggests adding
> an acknowledge return as well as a final return. The THROW-EVENT
> procedure is specifically identified as at least one instance of a
> procedure that would incorporate a 3-phase operation (formerly the
> "Control_Directive" operation, now called simply "Directive" in the
> latest draft CSTS Procedures Definition Recommendation (v0.5)).
> 
> Presumably, the Directive operation would include the Standard
Confirmed
> Operation Header defined in section 4.2 of the CSTS Procedures
> Definition. However, that standard header makes mention only of a
single
> Return.
> 
> There are several possible ways to address this problem:
> 
> 1. Leave the Standard Confirmed Operation Header as currently defined,
> and somehow extend it for the Directive operation to change the
"return"
> into a "final return" and to add an "acknowledge return". This seems a
> bit awkward, in that it redefines a major massage type (the return).
> 
> 2. Define the Standard Confirmed Operation Header as the more-general
> case (e.g., with both an Acknowledge Return and a Final Return), and
> then limit the definitions of 2-phase operations to only returning
Final
> Returns. Yasunori Iwana essentially documented this 2-return-column
> approach for the Control-Directive operation in his draft CSTS Toolkit
> W06 document (in the CSTS Private/JAXA Proposal for CSTS Toolkit
> folder).
> 
> 3. Continue to define the Standard Confirmed Operation Header as
having
> a Return, but add the appropriate specifications to mandate that in
some
> cases two returns are sent, and add sufficient qualification to the
> parameters to identify which type of return is being sent. The
simplest
> way to do this would be to add another possible value ('acknowledged')
> to the result parameter. The definitions of 2-phase operations would
> exclude the possibility of the result parameter taking the
> 'acknowledged' value.
> 
> My current feeling is that option 3 is the least intrusive on the
> current structure of the header and its component parameter
definitions.
> 
> 
> How the three-phase operations are accommodated (or not) by the
standard
> headers is of particular interest to me, in that I will be working on
> the definition of the Directive operation and the THROW-EVENT
procedure
> that uses it. There may not be time in tomorrow's telecon to address
> this issue, but I hope that we can have an email discussion on the
> topic.
> 
> I have an additional comment on the definition of the Standard
Confirmed
> Operation Header as documented in the current CSTS Procedures
Definition
> draft. The name of the parameter "positive-result-return" is a bit
> inappropriate, because "return" is a reserved term and the name of the
> larger entity that contains that parameter. How about something like
> "positive-result-data"?
> 
> I'm looking forward to talking with you tomorrow.
> 
> 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
> _______________________________________________
> Css-csts mailing list
> Css-csts at mailman.ccsds.org
> http://mailman.ccsds.org/cgi-bin/mailman/listinfo/css-csts