[Css-csts] RE: Inadequate ASN.1 for GET diagnostic?
Yves.Doat at esa.int
Yves.Doat at esa.int
Sat Sep 8 09:52:44 EDT 2012
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/css-csts/attachments/20120908/e2d70962/attachment.htm
More information about the Css-csts
mailing list