[Css-csts] RE: Inadequate ASN.1 for GET diagnostic?
John Pietras
john.pietras at gst.com
Wed Sep 12 10:30:26 EDT 2012
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/ <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/20120912/481a04af/attachment-0001.html
More information about the Css-csts
mailing list