[Css-csts] CSTS - NOTIFY operation changes -
Object Identifiers updates
John Pietras
john.pietras at gst.com
Wed Jan 25 16:04:31 EST 2012
Yves,
Since items 1, 2b and 2 c are non-issues now, I will respond to your
answers for 2a and 2d.
First, regarding 2a: Thanks for the explanation, and especially for
pointing out the Annex J diagrams. I now understand the structure that
you intended and don't see any need to change. However, looking at the
material again after your response has raised a few more comments.
As you now have it set up, object identifiers for events are to be
defined under 3 branches: publishedIdentifiers (under CSTS), events
(under framework) and in procedure-specific event identifiers (under the
OID of the procedure).
1) publishedIdentifier. Section C3.2(c) of the December draft of
the Framework states "'publishedIdentifiers' lists all object
identifiers that defines names relevant for CSTS services." I think that
this is somewhat misleading because it implies that all OIDs will
somehow be registered under it, whereas of course there are OIDs being
defined under the events and procedure-specific event identifier
branches. The publishedIdentifiers branch is (I think) the branch under
which OIDs that are used by CSTS services can be defined outside of the
Framework or the CSTS service specifications themselves. That is, the
OIDs that are defined via an external registration authority (i.e.,
SANA). Also, to be consistent with our terminology, "names" are
constructed as pairs of published identifiers, not single identifiers. I
suggest that the description of publishedIdentifier in C3.2(c) be
changed to something like "'publishedIdentifiers' is the branch used to
register (with SANA) object identifiers that are both (1) used to define
names relevant for CSTS services and (2) not explicitly specified in the
CSTS Specification Frames or CSTS specifications." (I'll have more to
say about the publishedIdentifier branch later on).
I wonder if it is better to explicitly define the (agency acronym)
FunctionalResources in Annex C (as your current draft shows) or push
that out to the SANA registry. We should define the SANA procedure for
adding new agencies to the list in any case, and we could simply apply
that procedure from the beginning and just have these OIDs listed in
SANA.
NOTE - Annex C lists 41 agency FunctResources ids, whereas the Foreword
section of the CSTS SF Red-2 draft lists only 39 member and observer
agencies. Also, Annex C has two csaFunctResources identifiers: I think
one should be casFunctResources.
2) events. I see your logic now and don't have any problem with
keeping it the way it is. However, I think I was partially confused by
the description of this branch in C3.3(e): "The 'events' branch lists
the events defined in this Recommended Standard", which makes it sound
like all events (including procedure-specific ones) should somehow be
registered under it. A more-focused description would be something like
"The 'events' branch lists the events defined for the core NOTIFY
operation as specified in this Recommended Standard".
Also, in addition to the "FRAMEWORK EVENT IDENTIFIERS" (under the events
branch) specified on page C-8 Annex C, there appears to be a redundant
set of "EVENT IDENTIFIERS" on page C-9, under an otherwise-undefined
"eventsId" branch. This events/eventsId duality also exists in Annex J,
where figure J-2 shows "events" as branch 5 under framework, but figure
J-3 shows "eventsId" as branch 5 under framework. The "EVENT
IDENTIFIERS" section on page C-9 should be deleted, and "eventsId"
should be changed to "events" in figure J-3.
3) Procedure-specific event identifiers. Section C4.6(a) states
"the newly allocated number shall be complemented with two sub-numbers",
but then sub-bullet (3) adds a third sub-number. Furthermore, sub-bullet
(3) states "eventIdentifiers may be required to register procedure
events (e.g. Buffer Data Delivery Procedure)". This is different than
the first two sub-numbers, for which there is no "may require"
terminology. In fact, there is only one procedure (UDD) that uses the
derivedProcedures branch, and the AC and IQ procedures do not use their
extendedProcedureParameters* branch. Even so, xxxDerivedProcedures and
xxxExtProcedureParam branches are defined for each of the Framework
procedures, whether they have anything under them or not. The three
sub-branches should be treated consistently, e.g.,
a) Change "two sub-numbers" to "three sub-numbers" in C4.6(a),
remove the "may be required" phrase from the eventIdentifiers clause
(Section C4.6(a)(3) and define an xxxEventIdentifiers branch for every
Framework procedure in the ASN.1 in C5.5; or
b) Change "two sub-numbers" to "three sub-numbers" in C4.6(a), remove
the "may be required" phrase from the eventIdentifiers clause (Section
C4.6(a)(3), add a comment after the cyclicReport OID specification (page
C-8) "- Although all procedures nominally have three procedure
identifier branches, only those branches that are actually used in this
Recommended Standard are specified below", and delete the unused OID
specifications.
Other possibilities may exist: the above two are just examples of how to
treat the three branches consistently.
[* Although C4.6(a)(2) calls the branches "extendedProcedureParameters"
the ASN.1 specifications themselves use the "ExtProcedureParam" syntax.
I suggest that C4.6(a)(2) adopt the actual ASN.1 syntax for clarity and
consistency. Better yet, adopt the "(procedure name)ExtProcedureParam"
syntax that is similar to that in section C5.2.]
4) Finally, (at least as far as item 2a is concerned), I think that
Annex C should address the specification of events and parameters within
service specifications. The easy example of this is extension
notifications that a service adds for the NOTIFY operation of one of its
procedures. Such event identifiers need to be specified within the
specifications themselves, because they are explicitly defined by those
specifications. In addition to events, there should be the framework for
service-specific parameter identifiers (actually, identifiers for
qualified parameters). The simplest example of this would be a service
that implements an Information Query procedure to allow the user to GET
configuration parameters similar to today's SLE GET-PARAMETER
operations. Those gettable parameters would be defined as part of the
service specification.
Of course, the Framework specification cannot define the specific
branches for the services, which are outside the purview of the
Framework. But they can be added to the template for Service Object
Identifiers in section C5. I suggest the following changes to C5.2:
a) Change the last sentence of C5.2 from "... three sub-numbers" to
"... five sub-numbers";
b) Add sub-bullet (d): "(service name)ServiceEventIdentifiers to
register object identifiers for events defined by the service";
c) Add sub-bullet (e): "(service name)ServiceParameterIdentifiers to
register object identifiers for parameters defined by the service"; and
d) Change figure C-4 to show the additional branches.
You'll be happy to know that my comments on item 2d are shorter.
Basically, as far as Annex C is concerned, I think that the paramtersId
branch should have two specified sub-branches, one for Agency-defined
IDs (which encompasses parameter identifiers, event identifiers,
parameter list identifiers, and event list identifiers) and one for
CCSDS-standard IDs (which encompasses parameter identifiers and event
identifiers - I don't think that we'll have standard parameter list
identifiers and event list identifiers]).
The Agency branches would allow Agencies to register their own
(non-CCSDS-standard) parameter and event identifiers. Agency branch
(agencyParametersId?) could have its subbranches allocated to Agencies
for further suballocation (we could provide guidelines for structuring
those Agency subtrees, but it is probably simplest to let the Agencies
do it themselves. E.g., some Agencies may want to have a single
agency-wide list, whereas others may want to let their constituent
networks define separate identifiers). The actual agency identifiers
could be specified (e.g., cnsaParametersId) or deferred to SANA
registration (see (1), above).
Best regards,
John
From: Yves.Doat at esa.int [mailto:Yves.Doat at esa.int]
Sent: Monday, January 23, 2012 2:41 AM
To: John Pietras
Cc: css-csts at mailman.ccsds.org; css-csts-bounces at mailman.ccsds.org
Subject: RE: [Css-csts] CSTS - NOTIFY operation changes - Object
Identifiers updates
Dear John,
< non-relevant material deleted>
2. a) See attached file: "20120121 Alternatives OID for events"
< non-relevant material deleted>
2.d) requires some discussion as I worked out a proposal without any
preliminary discussions with the WG. I based the proposal on the
following argumentation (my understanding from Boulder meeting):
1. Each Agency has its own Functional Resource (FR);
2. In the current situation we do not want (we cannot embark) on
the standardisation of the FR across Agencies.
This statement implies that each Agencies must be able to
define its own FR;
In order to do so, I created one OID per Agency. Each Agency
will have to define its own FRs (1 OID per FR) under its OID
Example:
functionalResourceId OBJECT IDENTIFIER ::=
{ publishedIdentifiers 1}
cnsaFunctResources OBJECT IDENTIFIER
::= { functionalResourceId 8}
Under its own OID, CNES will allocate a list of CNES FR
with 1 OID per FR.
3. We will have a list of parameters (Published Identifiers) that
will be defined in the data dictionary
4. The parameters will be declared as Published Identifiers. Each
of them will get an OID under the branch defined by:
parametersId OBJECT IDENTIFIER ::= {
publishedIdentifiers 2}
5. Each Agency will identify which Published Identifier belongs
to which of its own FRs.
With this approach we have two independent branches: one for the FRs of
each Agency and one for the Published Identifiers.
Based on that approach each Agency will have to:
1. define its FRs
2. Identify which Published Identifier belongs to which FR.
Note: The structure allows to have the definitions outside the
Framework.
==================
I hope this clarify your questions.
Please let me know your preference on 2.a.
I am afraid, 2.d requires additional discussion. We have to make sure
the structure answers the need of the Agencies and the need of the
Monitoring service.
(As usual all members of the WG are welcome to question and comment this
discussion)
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:
06/01/2012 22:46
Subject:
RE: [Css-csts] CSTS - NOTIFY operation changes - Object
Identifiers updates
Sent by:
css-csts-bounces at mailman.ccsds.org
________________________________
Yves,
I've finally had the chance to look at the December version of the
Framework. I can't promise that these comments are comprehensive, but I
thought that I should get them to you while I have the chance - I will
be going out of town next week, and I'll be very involved in my Service
Management task for several weeks once I return.
< non-relevant material deleted>
2. I am a bit confused by the organization of the new object
identifiers related to published identifiers and events. I don't
necessarily think that it is wrong, but I am having difficulty in
following the organization.
a) I don't see the logic of registering "events" under "framework", and
then have a special bddEventIdentifiers branch under
bufferedDataDelivery. Since the events that are listed in the FRAMEWORK
EVENT IDENTIFIERS are all associated with the NOTIFY operations, I would
have expected them to be more closely associated with the NOTIFY
operation. Alternatively, if "events" remains directly under
"framework", then (to me) it would seem more logical to have something
like the following tree:
events OBJECT IDENTIFIER ::= {framework 5}
notifyEvents OBJECT IDENTIFIER ::= {events 1}
bddNotifyEvents OBJECT IDENTIFIER ::= {events 2}
< non-relevant material deleted>
d) The PUBLISEH (typo) IDENTIFIERS OBJECT IDENTIFIERS section defines
the parametersId branch as {publishedIdentifiers 2}, and the text in
C3.6 states "this branch lists the object identifiers of the parameters
defined by CCSDS. The list is registered with SANA." There will have to
be some structuring of this branch. Should it be by services created
using the Framework, and if so, what about parameters that are used by
multiple services - can we construct the SANA registry such that it
"imports" OIDs from another service's registry?
This section also establishes the functionalResourceId branch (as
{publishedIdentifiers 1}), to "list per Agency the functional resource
identifiers of each Agency." The Framework then goes on to establish
top-level branches for each Agency under this branch. Again, we will
have to develop rules for how Agencies use this branch.
A number of questions are brought to mind by these two registration
branches. For example, the FR IDs identify specific instances of FR
types. CCSDS (via Wolfgang's work) is developing the set of standard FR
types as well as the standard set of monitored parameters associated
with those FR types. What is the mechanism for identifying theses FR
types, and how do the FR IDs that each Agency registers under its
xxxFunctResources branch get associated with the appropriate FR types?
Is it simply by textual description? Other questions are: how do
Agencies register Agency-unique FR types and the parameters that are
associated with them, and how do Agencies register Agency-specific
parameters for CCSDS-standard FR types?
I don't know if these questions need to be answered in the Framework,
but in any case we should have a clear idea of how the subregistries
will "look" in SANA and that they will support all of the realistic use
cases.
Best regards,
John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/css-csts/attachments/20120125/999b79bd/attachment-0001.htm
More information about the Css-csts
mailing list