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

[John Pietras]

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

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/css-csts/attachments/20120509/3ac67b15/attachment.htm