[Css-csts] FW: Some questions about ASN.1 and syntax commonality
Yves.Doat at esa.int
Yves.Doat at esa.int
Mon Apr 28 10:44:33 EDT 2008
Dear John,
Please find below some answers.
1. You are fully right and I overlooked that requirement in the ASN.1
Looking at the definition I see that the ASN.1 allows a value with whatever
qualifier we have. I propose to strengthen the ASN.1 specification with the
following definition:
QualifiedParameter ::= SEQUENCE
{ publishedName PublishedName
, qualifiedValue CHOICE
{ valid [0] Value -- Valid value
, unknown [1] NULL -- Unknown & unavailable value
, undefined [2] NULL -- Undefined in the context
, error [3] Value -- Processing resulted in an error
}
}
This ASN.1 definition enforces that unknown and undefined are always sending
'NULL'.
As we do not send anymore a value, the requirement would then read:
If the value qualifier of a given parameter is ‘unknown’ or
‘undefined’, the invoker shall replace the returned value by a ‘null’
2. The following ASN.1 is used:
GetReturn ::= StandardReturnHeader
The StandardReturnHeader contains a positive and a negative possibility.
The negative return is foreseen in case of 'unknown names', 'maximum number
exceeded' so that the provider has to reject the request.
Do we consider 'unknown' and 'undefined' as negative return? The parameters
exist but it's just that in that context their value is undetermined and the
production cannot provide them. Negative return are triggered by the
provision while the value qualifier are provided by the production. My first
preference is not to consider them with a negative return.
To be discussed.
3. You are right regarding the MoM but I do not intend to reissue the MoM.
3.a In fact the data parameter in ASN.1 is defined as "extended" and not
refined.
TransferDataInvocation ::= SEQUENCE
{ standardInvocationHeader StandardUnconfirmedInvocationHeader
, generationTime Time
, dataContinuity CHOICE
{ firstDUafterProdStart [0] INTEGER (-1)
, directSuccessorDU [1] INTEGER (0)
, numberOfLostDU [2] INTEGER (2 .. 65535)
, undeterminedLostDU [3] INTEGER (1)
}
, sequenceCounter IntPosLong
, data Extended
, extensionParameter Extended
}
'data' is defined as an extension and no definition is provided.
I think a refinement would be to define the data as an octet-string and the
procedure would refine the octet-string as a QualifieParameter. Note that in
Appendix C we state (C.1.10) "If not used the Extended parameter shall carry
a NULL value."
A refinement could as well be the selection of a subset of an ASN.1
enumeration
In both cases I would know how to refine the ASN.1.
I propose to rephrase the text and speak about extension and not refinement.
3b. As you can see above the TRANSFER-DATA operation contains a field "data"
that is not defined.
The Cyclic report could define the data to be transferred as follows (Similar
as for the GET):
YourData ::= SEQUENCE
{ qualifiedParameters SEQUENCE OF QualifiedParameter
, extensionParameter Extended
}
Would that solve your problem?
4.
GET operation: Checking the ASN.1 I discovered that the GET extended
diagnostics are missing and I have to add them (unknown names and maximum
number of parameters exceeded).
I have to look into this missing specs and propose a suitable approach.
In 4.b you propose to remove 'unknown' from the ValueQualifier. The unknown
of the ValueQualifier (provided by the production) is different from the
"unknown parameter" returned (provided by the production).
5. Will be corrected in 0.13
I hope I correctly understood all your points.
Best regards
Yves DOAT
__________________________________________________
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
Sent by: <css-csts at mailman.ccsds.org>
css-csts-bounces at m cc
ailman.ccsds.org
Subject
[Css-csts] FW: Some questions about
22/04/2008 16:37 ASN.1 and syntax commonality
CSTSWG colleagues --
In preparing for next week's telecon, I realized that I neglected to
copy the CSTSWG on the email message below. I would like to discuss this
issue if there is time available at next week's telecon.
Best regards,
John
-----Original Message-----
From: John Pietras
Sent: Friday, March 21, 2008 5:37 PM
To: 'Yves.Doat at esa.int'
Subject: Some questions about ASN.1 and syntax commonality
Yves,
I've been looking at the MoM from Crystal City, and I've got some
questions about section 4.3 (Annex C - ASN.1). Perhaps my ASN.1 skills
are getting a bit rusty, but here goes ---
1. In the v0.12 Procedures Definition book, section 4.13.2.3.4 states
"If the value qualifier of a given parameter is 'unknown' or
'undefined', the returned parameter value shall be set to 'null'." The
ASN.1 for the QualifiedParameter type (in both the MoM and the ASN.1 in
v0.12) does not seem to allow a 'null' value for the value component. I
believe that this can be accommodated by defining the value component of
the QualifiedParameter type as:
value CHOICE
{ singleValue [0]
TypeAndValue
, multipleValues [1] SEQUENCE OF
TypeAndValue
, null [2] NULL
}
2. Also regarding the GET operation, the definition can be confusing
unless one reads the specification very carefully. The same
qualifiedParameters (list-of-parameters-values?) is returned in both the
positive and negative returns. For 'valid' parameter values, it seems
obvious that there should be a positive-result return, and section
4.13.2.3.4 explicitly states that if any of the parameters in the list
is unknown, a negative-result return shall be sent. But it's kind of
fuzzy what to do about 'undefined' and/or 'error' values. It's my
understanding that they still get returned in a positive result, but a
reader may think otherwise because both share the "the user shall not
process it" with unknown values.
The potential for confusion might be reduced by adding another clause
along the lines of:
"If all parameters in the list-of-parameters are known and have valid,
undefined, or errored values then the GET operation shall return a
positive result. "
3. The caption of the ASN.1 snippet of section 4.3 of the MoM is
"TRANSFER-DATA - Parameter Definition for Monitoring Service". Wouldn't
it be more accurate to call it "TRANSFER-DATA - Parameter Definition for
the Cyclic Report Procedure" (which happens to be used by the Monitored
Data Service)? This ASN.1 will apply to all Cyclic Report Procedure
usages, not just Monitored Data. Assuming that the ASN.1 in the MoM does
indeed apply to the Cyclic Report procedure, there are a few other
points:
a. The ASN.1 in the MoM states that the data parameter is *extended*
as a QualifiedParameter. But in section 5.8.4.2.3.1.1 of the v0.12
Procedures Definition, it states "The data parameter has been *refined*
for Cyclic report procedure usage: ...". I believe that refinement (not
extension) is the correct model for what is happening to the data
parameter. How can that be expressed in ASN.1?
b. The ASN.1 appears to refine/extend the TRANSFER-DATA invocation
data parameter as one instance of the QualifiedParameter type. But the
Cyclic Report procedure is to be able to report multiple monitored
parameters concurrently in the same TransferDataInvocation. Shouldn't
the refinement/extension be as a SEQUENCE OF QualifiedParameter?
c. For the TRANSFER-DATA operation in the Cyclic Report procedure,
the QualifiedParameter qualifier value 'unknown' would never appear.
Will it be sufficient to specify in the definition of the Cyclic Report
procedure only the values that are valid for that operation (valid,
undefined, and error), or will the specification need to explicitly
exclude 'unknown'?
4. Regarding increasing the commonality of the START operation, section
5.8.4.1.2.3.2 of the v.012 Proc Defn (in the section that defines the
START operation for the Cyclic Report procedure) states " 5.8.4.1.2.3.3
If at least one of the parameters of the list is unknown, then the START
operation shall return a negative result and the diagnostic shall
contain the list of unknown parameters." This is also the way
Notification procedure START operation is currently defined, as it was
patterned after the Cyclic Report in this respect.
However, making the list of unknown parameters part of the diagnostic is
inconsistent with the approach for the GET (in which the diagnostic
merely indicates the existence of unknown parameters, but the
identification of the unknown parameters is carried in the
list-of-parameter-values. I can think of two ways to make these
operations work more consistently:
a. In the START operation for the Cyclic Report and Notification
procedures, make the list-of-parameters parameter (which is mandatory in
the invocation) conditional in the START return. If the return is a
negative result with diagnostic = 'unknown names', then the
list-of-parameters also appears in the return and contains only the
unknown names. The diagnostic would not have the list.
-OR-
b. Redefine the QualifiedParameter ASN.1 type to have only the
qualifiers 'valid', undefined', and 'error' (that is, delete 'unknown').
For the TRANSFER_DATA operation in the Cyclic Report procedure this will
work fine. For the GET operation, change the 'unknown names' diagnostic
value to include the list of unknown names (as currently specified for
the Cyclic Report and Notification procedures). The conditional
parameter list-of-parameters would only be reported in a
positive-result.
I think that option (b) has the advantage that it makes the use of the
QualifiedParameter type consistent for use only in positive returns (or
invocations, in the case of TRANSFER-DATA). For that reason, I like it
better than (a)
5. Finally, I found multiple instances of "ExecutiveDirective" instead
of "ExecuteDirective" in the ASN.1 in v0.12.
Best regards,
John
_______________________________________________
Css-csts mailing list
Css-csts at mailman.ccsds.org
http://mailman.ccsds.org/cgi-bin/mailman/listinfo/css-csts
More information about the Css-csts
mailing list