[Css-csts] RE: NotificationTypes
Yves.Doat at esa.int
Yves.Doat at esa.int
Fri Feb 1 06:12:37 EST 2013
Dear John,
Please find attached the updated Annex D with my proposed changes (marked):
Editorial change in the first sentence;
Section D.8 added explaining how to define a new parameter, event and
directive (various fields) and how to register with SANA.
I updated 3.10.2.2.3.4 with your proposal.
(See attached file: 921x1r2[Draft 201301] - Appendix D.pdf)
I will go once more (quickly) through the document and if Ok with you I will
upload the new version prior to the teleconference.
Best regards
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" <Yves.Doat at esa.int>
Cc: "CCSDS_CSTSWG (css-csts at mailman.ccsds.org)" <css-csts at mailman.ccsds.org>
Date: 18/01/2013 16:24
Subject: RE: NotificationTypes
Yves,
Thank you for the clarification - your response answers my questions.
In light of your response, I revisited requirement 3.10.2.2.3.4, which
states:
"The events defined by the NOTIFY operation shall be transferred with the
Functional Resource Identifier of the service triggering the events.”
A (cross suport transfer) service is one type of Functional Resource that can
emit event notifications, but it is not the only type. I think that the
more-general and correct wording of this requirment should be
"The events defined by the NOTIFY operation shall be transferred with the
Functional Resource Identifier of the Functional Resource instance triggering
the events.”
In order to keep all of these proposed changes together “under one cover”,
I’ve created an update of my previous modified version that contains the
proposed change to 3.10.2.2.3.4 and your update to 3.10.2.2.3.5, “921x1r2
[Draft 201301] - Return Services-JVP+YD” which I’ve uploaded to the CWE at
URL
http://cwe.ccsds.org/css/docs/CSS-CSTS/CWE%20Private/CSTS%20Framework%20and%20Concept/921x1r2%5BDraft%20201301%5D%20-%20Return%20Services-JVP
+YD.doc
Best regards,
John
-----Original Message-----
From: Yves.Doat at esa.int [mailto:Yves.Doat at esa.int]
Sent: Friday, January 18, 2013 5:31 AM
To: John Pietras
Cc: CCSDS_CSTSWG (css-csts at mailman.ccsds.org); John Pietras
Subject: RE: NotificationTypes
Dear John,
I wish you all the best in 2013 with a fantastic Framework Red Book.
I see that you have been working very hard and I really appreciate the
various inputs you submitted.
I cross-checked with Margherita your mails and we agreed on the following:
The ASN.1 definition is correct;
The requirement 3.10.2.2.3.5 is a left over from previous definition which
intended to allow a new service to define events to their liking. With the
new approach the event definition is contraints by the agreed structure
starting from Functional Resources. The requirement will be removed.
The notificationTypeExtension is inserted to allow an event to carry
additional information. This additional information must be defined at the
time of event definition.
A new 3.10.2.2.3.5 has been created :
"Events defined by the NOTIFY operation may be transferred with additional
information to be carried by the type notificationTypeExtension."
The eventValues of the Framework events are specified to contain a null
value (See requirement 3.10.2.2.3.2). There is no change to the document.
I hope those four points answer your two emails. If you still have a problem
with that approach, please let me know.
Best regards
Yves
From: John Pietras <john.pietras at gst.com>
To: John Pietras <john.pietras at gst.com>, "Yves.Doat at esa.int" <
Yves.Doat at esa.int>
Cc: "CCSDS_CSTSWG (css-csts at mailman.ccsds.org)" <
css-csts at mailman.ccsds.org>
Date: 26/12/2012 16:44
Subject: RE: NotificationTypes
Yves,
Another question just occurred to me. The four published events defined for
the NOTIFY operation (production configured, production interrupted,
production halted, and production operational) do not have eventValues
associated with them. Are procedures that use the NOTIFY operation allowed to
add eventValues for one or more of them, or are they restricted to only
having event names? Either way, I think that 3.10 should address it.
John
From: css-csts-bounces at mailman.ccsds.org [
mailto:css-csts-bounces at mailman.ccsds.org] On Behalf Of John Pietras
Sent: Wednesday, December 26, 2012 10:25 AM
To: Yves.Doat at esa.int
Cc: CCSDS_CSTSWG (css-csts at mailman.ccsds.org)
Subject: [Css-csts] NotificationTypes
Yves,
In preparation for writing the new annex that will explain how
parameter/event/directive names are formed, I’ve been reviewing the various
sections of the December draft of the CSTS SFW that makes use of those names.
In the specification of the NOTIFY operation (3.10), paragraph 3.10.2.2.3.5
states “All procedures shall have the possibility to extend the
notification-type parameter with additional event-names”.
The specification of the NotificationTypes ASN.1 type in Annex D3.3 is
-- The definition of the Notification types follows the definition in
-- 3.10.2.2.3 and the types are defined by the Object Identifers
-- productionConfigured, productionInterrupted, productionHalted and
-- productionOperational (see C7).
NotificationTypes ::= SEQUENCE
{ eventName ParamOrEventName
, eventValue CHOICE
{ text [0] VisibleString
, empty [1] NULL
}
, notificationTypeExtension Extended
}
I may be wrong (very possible since I have been away from this for a while),
but there seems to be an inconsistency between paragraph 3.10.2.2.3.5 and the
ASN.1 type definition.
My understanding of the approach is that *all* notifiable events are to be
defined as (eventName:eventValue) pairs (where eventValue is optional; that
is, it may have a null value), and this is consistent with what paragraph
3.10.2.2.3.5 says.
However, the ASN.1 type specification contains the notificationTypeExtension
parameter, which seems to add another, different type of extension mechanism
that is not otherwise addressed in section 3.10. Furthermore, because
NotificationTypes is defined as the SEQUENCE {eventName, eventValue,
notificationTypeExtension}, notificationTypeExtension appears to extend the
notification named by eventName, and not add a new syntax for defining a
notification-type . Is this the intended interpretation of
notificationTypeExtension ? If so, then there should probably be some
explanation in section 3.10.
Or is the inclusion of the notificationTypeExtension parameter merely an
erroneous carry-over from the normal way that parameter extension is provided
in the CSTS SFW?
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.
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 --------------
A non-text attachment was scrubbed...
Name: 921x1r2[Draft 201301] - Appendix D.pdf
Type: application/pdf
Size: 124283 bytes
Desc: not available
Url : http://mailman.ccsds.org/pipermail/css-csts/attachments/20130201/4332b59d/921x1r2Draft201301-AppendixD-0001.pdf
More information about the Css-csts
mailing list