[Css-csts] FW: Some questions about ASN.1 and syntax commonality

[John Pietras]

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