[Css-csts] RE: Comments on published identifiers, etc.

John Pietras john.pietras at gst.com
Thu May 10 09:55:46 EDT 2012


Yves,
Regarding the need to include (non-null) FR IDs for events (and parameters and directives) that are generated by the CSTS instances: I can see how your proposal to tag such events with the FR IDs of those CSTS instances would work. However, I have a concern about deferring the specification of the Event Identifiers of such events to the individual service specifications themselves. It would create a lot of redundant OIDs (e.g., every CSTS type would have a set of OIDs for the standard 4 production status change events), and it would push a lot more work onto the definers of the new services.

Instead, for events (parameters/directives) that are defined by Framework operations and procedures, we could still allow the OIDs for those events, etc., to be defined as part of the Framework, but still report them using the FR ID of the service instance that uses the operation/procedure that defines that OID.

 I see that in the updated Annex C that each procedure still has eventIdentifiers branches under the procedure identifier subtree. 

Under this proposed scheme, the event-name for the productionOperational being reported by the BDD procedure of the XXX-CSTS instance would look something like:

Event-name = [FR ID : Event Identifier], where
FR ID = [<XXX-CSTS FR type OID> : <XXX-CSTS FR instance>] and
Event Identifier = [<OID of productionOperational event under BDD eventIdentifiers subtree>]

I hope that we can talk about this during the telecon in a few minutes.

Best regards,
John

-----Original Message-----
From: Yves.Doat at esa.int [mailto:Yves.Doat at esa.int] 
Sent: Wednesday, May 09, 2012 4:43 PM
To: John Pietras
Cc: css-csts at mailman.ccsds.org
Subject: Re: Comments on published identifiers, etc.

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