[Css-csts] RE: Inadequate ASN.1 for GET diagnostic?
John Pietras
john.pietras at gst.com
Wed Sep 12 11:46:24 EDT 2012
Yves,
Yes, that fixes the discrepancy between the text and the ASN.1, as long as it is made in all three sections (3.11.2.3.1 (a), 4.7.4.1.3.1 (a), and
4.8.4.1.3 (a)).
Best regards,
John
-----Original Message-----
From: Yves.Doat at esa.int [mailto:Yves.Doat at esa.int]
Sent: Wednesday, September 12, 2012 11:40 AM
To: John Pietras
Cc: css-csts at mailman.ccsds.org
Subject: RE: Inadequate ASN.1 for GET diagnostic?
Dear John,
I also realised the issue when I read Sylvain's comments.
As a consequence I rephrased the diagnostic as follows:
"a) ‘unknown Functional Resource Identifier’ — one or more Functional Resource
Identifier contained in the list-of-events are unknown to the Service Provider (see 4.8.4.1.2.2). The list of unknown Functional Resource Identifiers shall be returned with the diagnostic;"
The ASN.1 reads as follows:
ListOfParamEventsDiagnostics ::= CHOICE
{ unknownFunctionalResourceIdentifier [1] SEQUENCE OF
FunctionalResourceIdentifier
, unknownParamEventIdentifier [2] SEQUENCE OF ParamOrEventName
, unknownListName [3] VisibleString
, maximumNumberExceeded [4] SEQUENCE
{ text AdditionalText
, maxNumber IntPos -- Maxi supported number
}
, undefinedDefault [5] AdditionalText
}
Let me know if that answer this last point.
Best regards
Yves
From: "John Pietras" <john.pietras at gst.com>
To: <Yves.Doat at esa.int>
Cc: <css-csts at mailman.ccsds.org>
Date: 12/09/2012 16:30
Subject: RE: Inadequate ASN.1 for GET diagnostic?
Yves,
The approach to use a common type is very good and eliminates the differences in the ASN.1 for the different uses of that type. Your consolidation of the material into a common type led me to realize that I made a mistake in interpreting what should be returned when the error is what is now called the ‘unknown Functional Resource Identifier’ occurs.
- Section 3.11.2.3.1 (a) ends with “The list of unknown
Parameter Names shall be returned with the diagnostic.”
- Section 4.7.4.1.3.1 (a) ends with “The list of unknown
Parameter Names shall be returned with the diagnostic.” And
- Section 4.8.4.1.3 (a) ends with “The list of unknown Event
Names shall be returned with the diagnostic.”
When I read these requirements while preparing my comments, I somehow overlooked that even though the error was an unknown FR Identifier, what was to be returned was the complete Parameter or Event Name that contains that unknown FR ID. I suggested that only the FR ID be returned, and you put that in your new ListOfParamEventsDiagnostics type. To conform to 3.11.2.3.1 (a),
4.7.4.1.3.1 (a), and 4.8.4.1.3 (a), the type definition for ListOfParamEventsDiagnostics should be
ListOfParamEventsDiagnostics ::= CHOICE
{ unknownFunctionalResourceIdentifier [1] SEQUENCE OF
ParamOrEventName
, unknownParamEventIdentifier [2] SEQUENCE OF
ParamOrEventName
, unknownListName [3] VisibleString
, maximumNumberExceeded [4] SEQUENCE
{ text AdditionalText
, maxNumber IntPos -- Maxi
supported number
}
, undefinedDefault [5] AdditionalText
}
This is actually what you had in the earlier NotificationStartNegReturnDiagnosticsExt type. My apologies for making a suggestion based upon a misreading of 3.11.2.3.1 (a), 4.7.4.1.3.1 (a), and
4.8.4.1.3 (a).
Best regards,
John
From: Yves.Doat at esa.int [mailto:Yves.Doat at esa.int]
Sent: Saturday, September 08, 2012 9:53 AM
To: John Pietras
Cc: css-csts at mailman.ccsds.org
Subject: RE: Inadequate ASN.1 for GET diagnostic?
Dear John,
DIAGNOSTICS
You are right, the Service Provider only knows that the Function Resource Identifier is incorrect but may not be in a position to identify if the FR Instance or the Type is incorrect. I merged the 2 diagnostics into one called "Unknown Functional Resource Identifier".
3.11.2.3.1 If a negative GET return is sent, one of the diagnostics
specified in 3.3.2.6.2, or one of the following diagnostics shall be used:
a) ‘unknown Functional Resource Identifier’ — one or more Functional Resource Identifier contained in the list-of-parameters are unknown to the Service Provider (see 3.11.2.2.2). The list of unknown Parameter Names shall be returned with the diagnostic;
4.7.4.1.3.1 If a negative START Return is sent, the diagnostic
parameter shall use one of the diagnostic values specified by the START in the Unbuffered Data Delivery procedure (see 4.6.3.3), or one of the following
values:
a) ‘unknown Functional Resource Identifier — one or more Functional Resource Identifier contained in the list-of-parameters is unknown to the Service Provider (see 4.7.4.1.2.3). The list of unknown Parameter Names shall be returned with the diagnostic;
4.8.4.1.3 If a negative START Return is sent, the diagnostic parameter shall use one of the diagnostic values specified in 3.7.2.3, or one of the following values:
a) ‘unknown Functional Resource Identifier’ — one or more Functional Resource Identifier contained in the list-of-events are unknown to the Service Provider (see 4.8.4.1.2.2). The list of unknown Event Names shall be returned with the diagnostic;
ASN.1
The ASN.1 definitions are not in line with the expectations and I reworked them as per your proposal.
Considering that the Get diagnostics, Cyclic Report Start diagnostics and Notification Start diagnostics are very similar, I created a new type (
ListOfParamEventsDiagnostics) in the Common Types module The following new definitions have been entered:
ListOfParamEventsDiagnostics ::= CHOICE
{ unknownFunctionalResourceIdentifier [1] SEQUENCE OF
FunctionalResourceIdentifier
, unknownParamEventIdentifier [2] SEQUENCE OF
ParamOrEventName
, unknownListName [3] VisibleString
, maximumNumberExceeded [4] SEQUENCE
{ text AdditionalText
, maxNumber IntPos -- Maxi
supported number
}
, undefinedDefault [5] AdditionalText
}
GetDiagnosticsExt ::= CHOICE
{ common [0]
ListOfParamEventsDiagnostics
, extensionDiagnostics [100] Extended
}
CyclicReportStartDiagnosticExt ::= CHOICE
{ common [0]
ListOfParamEventsDiagnostics
, outOfRange [1] AdditionalText
, extensionDiagnostics [100] Extended
}
NotificationStartNegReturnDiagnosticsExt ::= CHOICE
{ common [0]
ListOfParamEventsDiagnostics
, extensionDiagnostics [100] Extended
}
Functional Resource Instance
I renamed in the book "Functional Resource Instance" to "Functional Resource Instance Number"
Please let me know if the approach solves the issues you noted.
Yves
__________________________________________________
Head of the Ground Facilities Infrastructure Section (HSO-ONI) in the Ground Facilities Operations Division 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/
__________________________________________________
From: "John Pietras" <john.pietras at gst.com>
To: <Yves.Doat at esa.int>
Date: 24/08/2012 19:42
Subject: RE: Inadequate ASN.1 for GET diagnostic?
Yves,
In my note yesterday (below) I pointed out several references to the use of “functional resource instance” when I thought the intention was “functional resource Identifier”, in light of the fact that “functional resource instance” is currently defined in the CSTS SF as being the integer that distinguishes the functional resource type to form the functional resource identifier.
However, “functional resource instance” intuitively should refer to the instance itself and not just a qualifying number. I would like to suggest that instead of just calling that number the functional resource instance, it be called the functional resource instance number. That would allow the term “functional resource instance” to be used to refer to the actual FR instance itself. The semantics would then be that a functional resource instance is identified by a functional resource identifier, which is made up of the combination of a functional resource type and a functional resource instance number.
I realize that this is rather late in the game of preparing the Red Book for review, and I would not make it except that I believe that you will have to modify the book anyway to deal with the issues raised in the email below. I perfectly understand if you think that making this change now would be too much work, and I don’t think that it will affect the review of the Red Book too adversely if it doesn’t get in this round. However, I will probably submit a RID about this because I do believe that as currently defined the term functional resource instance is counter-intuitive and confusing.
Best regards,
John
From: John Pietras
Sent: Thursday, August 23, 2012 6:13 PM
To: Yves.Doat at esa.int
Subject: Inadequate ASN.1 for GET diagnostic?
Yves,
Section 3.11.2.3.1 of the July draft of the CSTS SF defines the diagnostic values for the GET negative result return as:
a) ‘unknown Functional Resource Type’ — one or more Functional Resource
Type contained in the list-of-parameters are unknown to the Service Provider (see 3.11.2.2.2). The list of unknown Parameter Names shall be returned with the diagnostic;
b) ‘unknown Functional Resource Instance’ — one or more Functional
Resource Instance contained in the list-of-parameters is unknown to the Service Provider (see 3.11.2.2.2). The list of unknown Parameter Names shall be returned with the diagnostic;
c) ‘unknown parameter identifier’ — one or more Parameter Identifier
contained in the list-of-parameters is unknown to the Service Provider (see 3.11.2.2.2). The list of unknown Parameter Names shall be returned with the diagnostic;
d) ‘unknown list name’ — the unknown list name shall be returned with the
diagnostic;
e) ‘maximum number exceeded’ — the number of parameters specified by
the invocation exceeds the maximum number of gettable parameters agreed; the maximum number of parameters supported by the Service Provider shall be returned with the diagnostic;
NOTE – The maximum number of gettable parameters is a service-specific
definition.
f) ‘default not defined’ — the default list (list-of-parameters left
empty) is unknown to the Service Provider.
And 3.11.2.3.2 specifies “ The type GetDiagnosticsExt, as defined in D3.5, shall define the syntax of the extended diagnostics defined in this section.”
But before getting to the ASN.1, I’d like to ask whether the diagnostic ‘unknown Functional Resource Instance’ is really the proper error, given that Functional Resource Instance is currently defined as the positive integer that is paired with the Functional Resource Type to form the Functional Resource Identifier. I think that what is desired here is ‘unknown Functional Resource Identifier’. This comment also applies to the diagnostics for the Cyclic Report START and Notification START operations.
Now to the ASN.1: in d3.5, GetDiagnosticExt is defined as
GetDiagnosticsExt ::= SEQUENCE
{ text AdditionalText
, list ListOfNamesDiagnosticsExt
}
Where ListOfNamesDiagnosticsExt is defined as
ListOfNamesDiagnosticsExt ::= CHOICE
{ unknownNames [1] SEQUENCE OF UnknownName
, maximumNumberExceeded [2] SEQUENCE
{ text AdditionalText
, maxNumber IntPos -- Maximum number supported
}
, unknownDefault [3] AdditionalText
, extensionDiagnostics [100] Extended
}
UnknownName is defined as
UnknownName ::= SEQUENCE
{ text AdditionalText
, name ParamOrEventName
}
ParamOrEventName is defined as
ParamOrEventName ::= SEQUENCE
{ functionalResourceId FunctionalResourceIdentifier
, paramOrEventId PublishedIdentifier
}
FunctionalResourceIdentifier is defined as
{ functionalResourceType PublishedIdentifier
, functionalResourceInstance IntPos
}
And PublishedIdentifier is defined as
PublishedIdentifier ::= OBJECT IDENTIFIER
This collection of type covers section 3.11.2.3.1 diagnostics (c) (I think), (e), and (f), but not items (a), (b), or (d).
I see that you did redo the diagnostics types for the CyclicReportStartDiagnosticExt type
CyclicReportStartDiagnosticExt ::= CHOICE
{ unknownFunctionalResourceType [1] SEQUENCE OF
ListOfParameters
, unknownFunctionalResourceInstance [2] SEQUENCE OF
ListOfParameters
, unknownParameterIdentifier [3] SEQUENCE OF
ListOfParameters
, unknownListName [4] ListOfParameters
, maximumNumberExceeded [5] SEQUENCE
{ text AdditionalText
, maxNumber IntPos -- Maxi supported number
}
, undefinedDefault [6] AdditionalText
, outOfRange [7] AdditionalText
, extensionDiagnostics [100] Extended
}
And the NotificationStartNegReturnDiagnosticsExt type NotificationStartNegReturnDiagnosticsExt ::= CHOICE
{ unknownFunctionalResourceType [1] SEQUENCE OF
ParamOrEventName
, unknownFunctionalResourceInstance [2] SEQUENCE OF
ParamOrEventName
, unknownEventIdentifier [3] SEQUENCE OF
ParamOrEventName
, unknownListName [4] VisibleString
, maximumNumberExceeded [5] SEQUENCE
{ text AdditionalText
, maxNumber IntPos -- Maxi supported number
}
, undefinedDefault [6] AdditionalText
, extensionDiagnostics [100] Extended
}
I am assuming that you had intended to do something simialr for the GET diagnostic extension but it just fell through the cracks. However, there are two errors with each of the CyclicReportStartDiagnosticExt and NotificationStartNegReturnDiagnosticsExt types.
In the CyclicReportStartDiagnosticExt type (above), unknownFunctionalResourceType is cast as SEQUENCE OF ListOfParameters, where ListOfParameters is defined as
ListOfParameters ::= CHOICE
{ defaultList [0] NULL
, parameterNames [1] SEQUENCE OF ParamOrEventName
, listName [2] VisibleString
, functionalResourceId [3] FunctionalResourceIdentifier
}
None of these choices has the syntax of a Functional Resource Type (i.e., just a PublishedIdentifier). unknownFunctionalResourceType should be recast as SEQUENCE OF PublishedIdentifier.
unknownFunctionalResourceInstance is also cast as SEQUENCE OF ListOfParameters. First, I think that this should be unknownFunctionalResourceIdentifier (see my comments above). Second, only one of the choices in ListOfParameters is applicable.
unknownFunctionalResourceIdentifier should be cast directly as SEQUENCE OF FunctionalResourceIdentifier (and maybe unknownFunctionalResourceIdentifier should be unknownFunctionalResourceIdentifiers to match the plurality of SEQUENCE OF).
unknownListName is also cast as SEQUENCE OF ListOfParameters. This should be recast as VisibleString.
In the NotificationStartNegReturnDiagnosticsExt type (above), unknownFunctionalResourceType is cast as SEQUENCE OF ParamOrEventName.
Functional Resource Type does not match the syntax of ParamOrEventName.
unknownFunctionalResourceType should be recast as SEQUENCE OF PublishedIdentifier.
unknownFunctionalResourceInstance is also cast as SEQUENCE OF ParamOrEventName. First, I think that this should be unknownFunctionalResourceIdentifier (see my comments above). Second – and more important – Functional Resource Identifier does not match the syntax of ParamOrEventName. unknownFunctionalResourceIdentifier should be cast directly as SEQUENCE OF FunctionalResourceIdentifier (and maybe unknownFunctionalResourceIdentifier should be unknownFunctionalResourceIdentifiers to match the plurality of SEQUENCE OF).
Best regards,
John
This message and any attachments are intended for the use of the addressee or addressees only. The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its content is not permitted. If you received this message in error, please notify the sender and delete it from your system. Emails can be altered and their integrity cannot be guaranteed by the sender.
Please consider the environment before printing this email.
This message and any attachments are intended for the use of the addressee or addressees only. The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its content is not permitted. If you received this message in error, please notify the sender and delete it from your system. Emails can be altered and their integrity cannot be guaranteed by the sender.
Please consider the environment before printing this email.
More information about the Css-csts
mailing list