[Css-csts] Re: Problems with defintion of positive-result parameter
and extension parameters of returns
Yves.Doat at esa.int
Yves.Doat at esa.int
Tue Sep 22 22:41:28 EDT 2009
Dear John,
Please find below my answers.
----------------------------------------------------
The Standard Header - Definition in table 3-1.
I fully concur with your comment. The approach is not in line with the other
sections of the book. I therefore accepted your comments. In addition I also
renumbered the requirements and headers such that the positive-result and
negative-result are now subsection of Results. I attach the new text to this
mail.
I have incorporated your new phrasing.
(See attached file: CSTS FW - Standard Operation Header 0.20.pdf)
---------------------------------------------------
ASN.1 - Your proposal:
Add for each of the return/acknowledge operation an extension
Remove the extension in the positive and negative result of the standard
header.
Explanation for the current approach:
When we started the definition, we did not have an extension for the negative
result. It was perceived that the extension for the positive result only was
required. Therefore the definition of the extension for the positive result
made sense. Some time later it appeared necessary to have an extension for
the negative result. This extension was added in the negative-result part. It
was agreed that this approach would avoid mixing positive and negative
extensions defined by the procedures and this was the main argument to keep
it that way.
Proposal:
All definitions are now based with two extensions one for positive and one
for negative result. While your proposal makes sense I cannot accept alone it
at this stage for the following two reasons:
The prototypes have been implemented and will most probably be used for
the evolution of the Framework;
The rework of the ASN.1 in the book takes some time and I cannot do that
in a few minutes
I propose the issue is discussed at the next teleconference. In the mean time
I will continue using the current approach.
--------------------------------------------------
BIND Operation - Table 3-3
I confirm that the 'responder identifier' is missing from the BindReturn -
Document updated
I added the following type and OID. Note that as a consequence the new ASN.1
will not be backward compatible with the version used in the Framework
prototype.
-- The negative BindReturn is returned using the negative extension of the
-- of the StandardReturnHeader (see 3.3),
-- (StandardReturnHeader:result:negative:extended)defined as Extended and
-- carrying the following information:
AssocBindNegReturnExt ::= SEQUENCE
{ responderIdentifier AuthorityIdentifier
, extensionParameter Extended
}
acBindNegReturnExt OBJECT IDENTIFIER ::= {acExtProcedureParam 3)
PROCESS-DATA Operation - Table 3-9
The 'sequence number is correctly represented in the 'negative return' - No
change to the document
ProcessDataNegReturnExt ::= SEQUENCE
{ sequenceCounter IntPos
, extension Extended
}
procDataNegReturnExt OBJECT IDENTIFIER ::= {procDataReturn 3}
Best regards
Yves
__________________________________________________
Head of the Stations and M&C Integration Section (OPS-GSI)
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
<Yves.Doat at esa.int>,
14/09/2009 23:50 <css-csts at mailman.ccsds.org>
cc
Subject
Problems with defintion of
positive-result parameter and
extension parameters of returns
Yves and CSTSWG colleagues ---
Table 3-1 of the CSTS FW lists the parameter positive-result as a conditional
parameter of the Acknowledgement and Return of the Standard Confirmed
Operation Header. However, there is no definition for the positive-result
parameter. Instead, the result parameter is defined (in section 3.3.2.6) such
that if the value of result is ‘positive result’, then “result may be
extended to carry additional information” (3.3.2.8.1).
Note that this is treated differently from the diagnostic parameter, which
also appears in table 3-1. Section 3.3.2.7.1 states “If result is ‘negative
result’, the diagnostic parameter shall be present in the acknowledgement or
return …”
However, in the actual operation definitions, any extension parameters of
positive-result returns are treated as new extensions of the returns
themselves, not as extensions of the result parameter. Furthermore, when
these extension parameters are added to specific returns (or
acknowledgements), if they are conditional their definitions state what those
conditions are (e.g., present only when the result = ‘positive result’).
I believe that this situation is similar to that in which we had (for a time)
explicit extension-parameter parameters. In that case, we decided that we
were confusing the intent to allow extension with the specific ASN.1
mechanism for supporting extension. We solved that problem by deleting the
extension-parameter parameters and inserting paragraph 3.2.1.7 into the
Framework (“Unless otherwise specified, all operations defined in this
Recommended Standard can be extended.”)
Paragraph 3.3.2.7.3 states “All procedures shall have the possibility to
extend the ‘negative result’ with additional information.” Again, I think
this is confusing how extension parameters are defined in the operation
tables vs. how they are encoded in the ASN.1. I think a more-correct
statement would be “All procedures shall have the possibility to extend
negative-result returns and acknowledgements with additional information.”
However, this points up one final problem that I have found: the ASN.1
supports extensions to positive-result or negative-result returns, but not
extensions that apply to each equally. We have two examples of parameters
that are to appear in the returns whether they are positive or negative, and
they are encoded erroneously in the ASN.1:
a) For the BIND operation, table 3-3 shows that the
responder-identifier is mandatory and version-number is conditional (on
a positive return). These two parameters appear in the
AssocBindPosReturnExt type, but the responder-identifier does not
appear in any extension structure for the negative-result return (which
it should).
b) For the PROCESS-DATA operation, table 3-9 shows the
data-sequence-counter parameter as mandatory. This parameters appears
in the ProcessDataPosReturnExt type for positive returns, but does not
appear in any extension structure for the negative-result return (which
it should).
I can think of two ways to solve this problem: (1) for each operation return
(or acknowledgement) parameter that is mandatory regardless of whether the
result is positive or negative, ensure that the extended parameter value of
the negative sequence of the result parameter in the StandardReturnHeader has
an extension type defined for it (as well as the extension type for the
positive value); or (2) add an extensionParameter parameter (of type
Extended) to the definition of the overall return for the operation, such
that the extension type applies regardless of whether the result is positive
or negative. Of these two options, I recommend the second one – it’s easier
to keep track of (only one extension type, not two), and it is more logical.
Extensions that are conditional on positive or negative results can continue
to be encoded as extensions of the positive or negative values of the result
parameter.
So, here are my suggestions for fixing the problems:
1. Rephrase paragraph 3.2.1.7 to clarify the extent to which operations
can be extended: “Unless otherwise specified, all operation
invocations, acknowledgements, and returns defined in this Recommended
Standard can be extended.”
2. Delete the positive-result parameter from table 3-1.
3. Change paragraph 3.3.2.7.3 to read: “All procedures shall have the
possibility to extend negative-result returns and acknowledgements with
additional information, the value of which shall depend on the
procedure using that operation.”
4. Change paragraph 3.3.2.8.1 to read: “All procedures shall have the
possibility to extend positive-result returns and acknowledgements with
additional information, the value of which shall depend on the
procedure using that operation.”
5. Delete paragraph 3.3.2.8.2.
6. In the ASN.1, change the BindReturn type to
BindReturn ::= SEQUENCE
{ returnHeader StandardReturnHeader
, extensionParameter Extended
}
7. Create an AssocBindReturnExt type to contain the responder-identifier
parameter and an extension parameter so that it extends any Bind
return.
8. Remove the responder-identifier parameter from the
AssocBindPosReturnExt type (since it’s already covered in the general
Bind return extension.
9. In the ASN.1, change the ProcessDataReturn type to
ProcessDataReturn ::= SEQUENCE
{ returnHeader StandardReturnHeader
, extensionParameter Extended
}
10. Change the ProcessDataPosReturnExt type to the
ProcessDataReturnExt type so that it extends any Process Data return.
Best regards,
John
John Pietras
GST, Inc.
7855 Walker Drive, Suite 200
Greenbelt, MD 20770
240-542-1155
-------------- next part --------------
A non-text attachment was scrubbed...
Name: =?UTF-8?B?Q1NUUyBGVyAtIFN0YW5kYXJkIE9wZXJhdGlvbiBIZWFkZXIgMC4yMC5wZGY=?=
Type: application/pdf
Size: 725192 bytes
Desc: not available
Url : http://mailman.ccsds.org/pipermail/css-csts/attachments/20090923/60bb49a5/UTF-8BQ1NUUyBGVyAtIFN0YW5kYXJkIE9wZXJhdGlvbiBIZWFkZXIgMC4yMC5wZGY-0001.pdf
More information about the Css-csts
mailing list