[Css-csts] Re: Comments on published identifiers, etc.
Yves.Doat at esa.int
Yves.Doat at esa.int
Wed May 9 16:43:02 EDT 2012
Dear John,
(I am just working on the updates and your comments arrived just on time).
I have just uploaded to the CWE the following files:
Annex C: Updated to be in line with our discussions and the teleconference
from last week.
"20120506 Object Identifiers - Framework Annex C - After Spring
meeting.ppt": updated OID presentation to be in line with our discussions
GET operation
Notify operation
Information Query procedure
Please find my answers hereafter:
I removed the note as when reading the document I considered that sending
the notification should not allow the 'null' but rather identify the list
itself. I found cleaner not to use the 'null' capability in the event
itself.
From the discussions my understanding is that the 4 events are to be
created by any new service.
E.g. in the case of the RAF service, the 4 events are added under the OID
of the RAF Functional Type (See example in the updated presentation).
As a consequence of my answer (2), the OID of the identified 4 events
cannot be defined in the Framework.
The ASN.1 in annex D has not yet been updated.
The incorrect cross-reference has been corrected.
I have not yet updated the Notification procedure. I copied your comment
in the Framework to be considered by next week.
This is a valid point which has been overlooked.
If we give the possibility to transfer events that are not related at all
to FR, we have to define for those two events a special case. To overcome
the issue, I propose the same as for the other 4 base events: request any
new service making use of that procedure to define the OIDs in the FR of
the corresponding events.
We have a teleconference tomorrow and we can address that point. Please
let us know your opinion before that teleconference.
I updated the tree as discussed in our teleconference with SM to allow
bilateral agreements.
Have a look to the newest uploaded files, they should answer to the
identified needs.
Please let me know your opinion.
Many thanks for your comments. I appreciated that you had the time to review
the updates.
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: 09/05/2012 20:20
Subject: Comments on published identifiers, etc.
Yves,
I’ve looked through the published identifier-related updates that you posted
to the CWE on 26 April, and have some comments.
1. In the NOTIFY operation, the event-name component of the
notification-type parameter was previously followed by “NOTE – In case
the value of the Functional Resource is not required, the structure
allows to use a ‘null’ in place of a Published Identifier.” The NOTE is
now gone. I think that it is still useful to be able to provide
notifications that have no specific functional resource (see other
comments below). The NOTE would be correct if “a Published Identifier”
is replaced by “the Functional Resource Identifier.”
2. In the NOTIFY operation, section 3.10.2.2.3.2 states “A
service using a procedure using the NOTIFY operation shall define the
Event Identifiers corresponding to the following published events
(event-name) (see annex C6) …” According to the new Additional
Definitions, Event Identifier is a Published Identifier. The ASN.1 in
the pre-Darmstadt CSTS SF should already define the OIDs for these
notification types, so the service/procedure doesn’t have to do this
(however, it doesn’t – see the next comment). What the
service/procedure has to do is define how to form the FR ID portion of
the event-names (whether it is applicable or not, and if it is, what
is/are FR type(s) that apply and how is the FR Instance set?).
3. The ASN.1 in the pre-Darmstadt CSTS SF should define the Event
Identifiers (OIDs) for the base notification types (
productionConfigured, productionInterrupted, productionHalted, and
productionOperational) , but it doesn’t. The OIDs *are* define in the
tables in Annex J. They need to be specified in the ASN.1 itself.
4. If you haven’t already made the change, the ASN.1 definition
of the ParamEventOrListName type needs to be changed to include the (FR
type: instance) nature of the FR ID. The current (pre-Darmstadt) draft
of the CSTS SF defines it as
ParamEventOrListName ::= SEQUENCE
{ functionalResource CHOICE
{ resourceIdApplicable [0] PublishedIdentifier
, resourceIdNotApplicable [1] NULL
}
, paramEventOrListId PublishedIdentifier
}
I think that it now needs to be something like
ParamEventOrListName ::= SEQUENCE
{ functionalResourceId CHOICE
{ resourceIdApplicable [0] SEQUENCE
{ functionalResourceType PublishedIdentifier
, functionalResourceInstance Integer
}
, resourceIdNotApplicable [1] NULL
}
, paramEventOrListId PublishedIdentifier
}
5. The definition of “parameter” as used for the GET operation
was formerly defined as part of the list-of-parameters parameter. The
definition is now referenced to a different section. Unfortunately, in
the PDF that was posted to the CWE, the reference for the definition is
now “Error! Reference source not found”.
6. Section 4.8.4.1.2.2.10 of the pre-Darmstadt CSTS SF draft
erroneously defines event names and event lists names as pairs of
Published Identifiers. This definitions need to be updated to reflect
the current name construction.
7. The NOTIFY operation needs to be able to handle notification
types that are not associated with any functional resource, because the
NOTIFY must be able to be used by procedures to report on events
associated with those procedures themselves. A case in point is the
NOTIFY operation that is part of the Buffered Data Delivery (BDD)
procedure. This NOTIFY extends the set of notification-types with
events ‘data discarded due to excessive backlog’ and ‘end of data’.
These events are generated by the CSTS instance itself and are not
attributable to another functional resource.
The ASN.1 for the BDD NOTIFY invocation states “The NotificationTypes
is refined with additional event types”. Is refined the correct term,
since this is adding values and not replacing (or refining) the
previously-specified values? Also, the term “event types” is not
defined and could lead to confusion. What’s being added are Event
Identifiers, yes? Finally, the “path” of the extension/refinement
(NotifyInvocation:NotificationTypes:eventName) is not complete. I think
that the path should be
(NotifyInvocation:NotificationTypes:eventName:ParamEventOrListId).
8. The updated Published Identifiers tree looks to have the
Agency branch removed. As I mentioned in Darmstadt, I think that it is
important to have hooks to allow Agencies to register/add their own
functional resource types and associated parameters, events, and
directives, and to be able to register/add Agency-unique parameters,
events, and directives to the CCSDS-standard functional resource types.
Is there general agreement on this, and if so, how can it be
accommodated in the CSTS OID tree?
Best regards,
John
John Pietras
GST, Inc.
7855 Walker Drive, Suite 200
Greenbelt, MD 20770
240-542-1155
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