[Css-csts] Problems with defintion of positive-result parameter and extension parameters of returns

[John Pietras]

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 --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/css-csts/attachments/20090914/cde802af/attachment.htm