[Css-csts] Parameter Names and Published Identifiers
Yves.Doat at esa.int
Yves.Doat at esa.int
Tue Nov 15 04:27:41 EST 2011
Dear John,
(Thanks for your comments and I tried to answer rapidly as I have little time
at the moment)
You are right, I wrote the text to define the parameter names and the
parameter list names to be constructed with a functional resource identifier
and a parameter identifier. The two are quite independent as you rightly
state. I do not remember stating that that the parameter list identifier is
constrained by a a single functional resource.
"B2.2 The parameter name shall be defined using two Published Identifiers:
one for the identification of the functional resource and the other to
identify the name of the parameter" I do not see in that that statement the
constraint you mention.
What may be missing in appendix B (around B2.2) are:
1. The statement that the parameter list names follow the same structure as
the parameter name;
2. The parameter identifiers are not constrained by the funcional resource.
The Functional Resource Identifier can be left unused as stated in the ASN.1
and in the note under B2.2: "In case the value of the Functional Resource is
unknown, the structure allows to use a ‘null’ in place of a Published
Identifier."
GET negative return "unknownName" diagnostic.
I changed the ASN.1 to:
ListOfNamesDiagnosticsExt ::= CHOICE
{ unknownNames [1] SEQUENCE
{ text AdditionalText
, name ParameterOrListIdentifier
}
, maximumNumberExceeded [2] SEQUENCE
{ text AdditionalText
, name IntPos -- Maximum number supported
}
, unknownDefault [3] AdditionalText
, extensionDiagnostics [100] Extended
}
A definition of functional resource is required in the Framework as we use
it.
In your definition of the functional resource type I agree with the first
sentence. However the second sentence introduces some additional notions that
(to my view) are not used in the book. Could we leave out this second
sentence?
Considering that the parameter name and functional resource are not
constrained in the Framework, I do not fully understand your last sentence.
The parameter names are not hard-coded in the Framework.
I look forward to reading your consolidated comments.
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: 14/11/2011 21:44
Subject: RE: [Css-csts] Parameter Names and Published Identifiers
Sent by: css-csts-bounces at mailman.ccsds.org
Yves,
I started to make detailed comments on your proposed changes, but then I had
a few questions that will affect what I had to write, and so I think I need
answers before proceeding with the detailed comments. My questions/concerns
were sparked by the realization that under the new “naming” convention as
outlined in your rewrite, the parameter list names are also pairs of
(functional resource identifier: parameter identifier). This implies that a
parameter list is constrained to a single functional resource. I was under
the impression that lists could have arbitrary content.
I noticed in the ASN.1 that the Functional Resource Identifier is optional,
although I didn’t see this mentioned in any part of the main text. This might
be one way around the issue: if parameter list names had no Functional
Resource (FR) ID component, they wouldn’t be restricted to a single FR. Is
this what you had in mind? In any case, I think that the notion that the FR
ID can be optional should be introduced in the main text.
Thinking about this issue made me wonder if we need to declare the (optional)
first part to always be an FR ID. I think the question came up in Boulder,
too. One possible option would be to leave it in the CSTS SF as a
more-generic “domain qualifier” (still a PublishedIdentifier/OID). For those
service for which Functional Resources as the qualifier are appropriate, the
domain qualifier would be refined as a Functional Resource Identifier in
those service specifications. Keeping this abstract in the CSTS SF gives us
some robustness in case we want to use one of these procedures for something
that does not readily map into functional resources (e.g., a file system?).
I’ll have some more detailed comments once I can frame them in terms of your
response to my question above.
One quick comment that I’ll make now: The ‘unknown names’ extension
diagnostic for the GET return is supposed to include “the list of unknown
parameter names”. However, when traced through in the ASN.1, it leads to the
type UnknownNames, which is currently specified as type VisibleString. I
think that this should be changed to match the new “pair of
PublishedIdentifier” definition.
While you think about those questions, here are some definitions from the
draft Monitored Data CSTS specification regarding functional resources:
1. Functional resource type – a logical function or related set
of functions that characterizes a unique instance of space
communication capability. A functional resource type can have at most
one of each monitored parameter type, each event notification type, and
each configuration parameter type.
2. Functional resource instance – An instance of a functional
resource type.
3. Functional resource identifier – the unique identifier of an
instance of a functional resource.
Using the Space Communication Cross Support Service Management (SCCS-SM )
terminology, examples of these three things are:
a) A return space link carrier is an example of a functional
resource type. In MD-CSTS, a monitored parameter type is associated
with a functional resource type. E.g., a carrier-lock status parameter
is associated with the return space link carrier functional resource
type.
b) A return S-band space link carrier that is received by the
ground station is an example of a functional resource instance. Note
that SCCS-SM allows a single service package to have carriers via
multiple ground station (or relay satellite) antennas executing
concurrently; that is, a single service package may have multiple
instances of S-band space link carrier executing. So in fact the
different instances might have to be qualified by, for example, the
antenna through with that carrier is received. The allows separate
carrier-lock statuses to be reported for each of the carriers in the
service package.
c) The identifier for one such return S-band space link carrier
is the OID that is assigned to that instance. Because multiple (in this
case, S-band) return space link carriers can be executing concurrently,
the set of functional resource identifiers must be capable of
distinguishing among these possible instances. For example, the NASA
Space Network is being upgraded to allow multiple return S-Band
antennas on multiple Tracking and Data Relay Satellites (TDRSs) to have
their signals combined, although the “carrier” associated with each of
those antennas will have its own set of monitored data (e.g., there
will be multiple carrier-lock statuses to report). In such a case, the
return S-band carrier functional resource identifiers will have to be
distinguishable by TDRS and the specific antenna on that TDRS (each
TDRS has 3 antennas that can receive at S-band).
I freely admit that the definition of functional resource type as “a logical
function or related set of functions that characterizes a unique instance of
space communication capability” is not very concrete, but it has to
generalize to a number of different types of entities, such as space link
carriers (when multiple such carriers can be active concurrently [e.g., in S
and X bands]), subcarriers (when multiple subcarriers can exist for a single
carrier), and SLE transfer service instances (of which there might be
multiple of the same type [e.g., RAF] operating concurrently. The key point
is that it is a type for which multiple instances can be operating
concurrently in the Service Package, such that a monitored parameter, control
parameter, or event notification associated with that type must be qualified
by an instance identifier to distinguish it from the other instances of the
same parameter type. E.g., the lock status of the return X-band carrier must
be distinguishable from the lock status of the return S-band carrier if both
happen to be operating concurrently. I welcome any suggestions for a better,
more compact, less abstract definition of functional resource type.
If we hard-code the parameter names to include functional resource
identifiers in the CSTS SF, then these definitions (or better ones) should be
moved into the CSTS SF. However, if we decide to use a more-abstract “domain
qualifier” (or some better name) notion in the Framework, then these
definitions can stay in the MD-CSTS.
Best regards,
John
From: css-csts-bounces at mailman.ccsds.org [
mailto:css-csts-bounces at mailman.ccsds.org] On Behalf Of Yves.Doat at esa.int
Sent: Monday, November 07, 2011 2:45 AM
To: css-csts at mailman.ccsds.org
Subject: [Css-csts] Parameter Names and Published Identifiers
Dear all,
Following our discussions last week, I updated the Framework to cope with the
requirements of the Monitored Data Service. I modified the book to define the
parameter name as a concatenation of a Functional Resource Identifier and a
Parameter Identifier.
Please find an extract of the book covering:
GET operation (pages 1 to 3) making use of parameter name
Information Query Procedure (pages 4 to 7) making use of parameter name
Cyclic Report Procedure (pages 8 to 15) making use of parameter name
Annex B (pages 16 to 17) with a new requirement (B2.2) defining a
parameter name
Annex D.3.3 (pages 18 to 22) with the new ASN.1 type:
ParameterOrListIdentifier being a concatenation of a Functional
Resource Identifier and a Parameter Identifier (used for the parameter
name)
I extracted those parts as it may be easier to review that topic separated
from the entire book. In case you would prefer to review the entire book, I
would make available an intermediate version on the CWE web site.
To John and Fred:
We have introduced the notion of Functional Resource and I was looking for a
definition without success. Could you please let me know where can I find
one? Alternatively, could you please propose one?
Considering the short planning discussed in Boulder, I would appreciate to
get rapid feed back. If you would prefer we coud organise a short
teleconference to review that topic.
Best regards
Yves
===============================================
GST IT DEPARMENT
===============================================
WARNING
Please, dont open pdf files from unknown source.
Adobe confirms PDF zero-day attacks. Disable JavaScript now.
http://blogs.zdnet.com/security/?p=5119&tag=nl.e589
_______________________________________________
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