[Css-csts] RE: NotificationTypes

Fri Jan 18 10:24:38 EST 2013

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<mailto:john.pietras at gst.com>>

  To:         John Pietras <john.pietras at gst.com<mailto:john.pietras at gst.com>>, "Yves.Doat at esa.int<mailto:Yves.Doat at esa.int>" <Yves.Doat at esa.int<mailto:Yves.Doat at esa.int>>

  Cc:         "CCSDS_CSTSWG (css-csts at mailman.ccsds.org<mailto:css-csts at mailman.ccsds.org>)" <css-csts at mailman.ccsds.org<mailto: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> [ 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<mailto:Yves.Doat at esa.int>

Cc: CCSDS_CSTSWG (css-csts at mailman.ccsds.org<mailto: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.

________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/css-csts/attachments/20130118/bd0fbe44/attachment-0001.htm