[Css-csts] CSTS - NOTIFY operation changes - Object Identifiers updates

[John Pietras]

Yves,

I've finally had the chance to look at the December version of the Framework. I can't promise that these comments are comprehensive, but I thought that I should get them to you while I have the chance - I will be going out of town next week, and I'll be very involved in my Service Management task for several weeks once I return.

 

1.    As currently defined, an instance of the type UnknownNames is really just a single name in two forms: (1) our OID-pair "machine-oriented" name and the human-readable text version that was put in at Tim's request (primarily for debugging, I believe). All uses of UnknownNames in the ASN.1 are in the form of

"unknownNames                 [1]   SEQUENCE OF UnknownNames"

For clarity, I suggest changing the type UnknowNames to UnknownName (that is, make it singular).

 

 

2.    I am a bit confused by the organization of the new object identifiers related to published identifiers and events. I don't necessarily think that it is wrong, but I am having difficulty in following the organization.

a) I don't see the logic of registering "events" under "framework", and then have a special bddEventIdentifiers branch under bufferedDataDelivery. Since the events that are listed in the FRAMEWORK EVENT IDENTIFIERS are all associated with the NOTIFY operations, I would have expected them to be more closely associated with the NOTIFY operation. Alternatively, if "events" remains directly under "framework", then (to me) it would seem more logical to have something like the following tree:

events            OBJECT IDENTIFIER ::= {framework 5}
notifyEvents      OBJECT IDENTIFIER ::= {events 1}
bddNotifyEvents   OBJECT IDENTIFIER ::= {events 2}


b) The current Data Processing procedure also adds notification types to the NOTIFY operation, but the ASN.1 doesn't treat these as published identifiers. I realize that you probably just ignored the Data Processing procedure since it's going to be redone, anyway, but whatever is released in Red-2 should be consistent with the rest of the document, even if it will be replaced in Red-3. This would mean adding:
dpEventIdentifiers      OBJECT IDENTIFIER ::= {dataProcessing 3} 


or (if you were to adopt the example alternative approach that I described in (a), above)

      dpNotifyEvents          OBJECT IDENTIFIER ::= {events 3}.


c) Although you have established the registration branch bddEventIdentifiers, in the BDD PDUs module the additional events 'dataDiscardedExcessBacklog' and endOfData' are defined as { bddProcedureParam 1} and {bddProcedureParam 2}, respectively. Shouldn't these have been {bddEventIdentifiers 1} and 
{bddEventIdentifiers 2} (or {bddNotifyEvents 1} and {bddNotifyEvents 2}, in the case of the formulation in item (a), above)?



d) The PUBLISEH (typo) IDENTIFIERS OBJECT IDENTIFIERS section defines the parametersId branch as {publishedIdentifiers 2}, and the text in C3.6 states "this branch lists the object identifiers of the parameters defined by CCSDS. The list is registered with SANA." There will have to be some structuring of this branch. Should it be by services created using the Framework, and if so, what about parameters that are used by multiple services - can we construct the SANA registry such that it "imports" OIDs from another service's registry?

This section also establishes the functionalResourceId branch (as {publishedIdentifiers 1}), to "list per Agency the functional resource identifiers of each Agency." The Framework then goes on to establish top-level branches for each Agency under this branch. Again, we will have to develop rules for how Agencies use this branch. 

A number of questions are brought to mind by these two registration branches. For example, the FR IDs identify specific instances of FR types. CCSDS (via Wolfgang's work) is developing the set of standard FR types as well as the standard set of monitored parameters associated with those FR types. What is the mechanism for identifying theses FR types, and how do the FR IDs that each Agency registers under its xxxFunctResources branch get associated with the appropriate FR types? Is it simply by textual description? Other questions are: how do Agencies register Agency-unique FR types and the parameters that are associated with them, and how do Agencies register Agency-specific parameters for CCSDS-standard FR types? 

I don't know if these questions need to be answered in the Framework, but in any case we should have a clear idea of how the subregistries will "look" in SANA and that they will support all of the realistic use cases. 

 

 

Best regards,

John

 

 

-----Original Message-----
From: Yves.Doat at esa.int [mailto:Yves.Doat at esa.int] 
Sent: Wednesday, December 21, 2011 7:10 AM
To: John Pietras
Cc: css-csts at mailman.ccsds.org; css-csts-bounces at mailman.ccsds.org
Subject: RE: [Css-csts] CSTS - NOTIFY operation changes - Object Identifiersupdates

 

Dear John,

 

Once more thank you for your effort.

 

I worked and cross checked the ASN.1 and found the same problem as you. I

also consider the following definition as incorrect:

NotificationTypes ::= CHOICE

{ eventName ParamEventOrListName

, eventValue VisibleString

, notificationTypeExtension Extended

}

(I simply forgot to replace CHOICE by SEQUENCE)

 

I replaced it by:

NotificationTypes ::= SEQUENCE

{ eventName ParamEventOrListName

, eventValue VisibleString

, notificationTypeExtension Extended

}

With that definition I have to admit that I force the specifier to define any

new event as an Object Identifier. This OID is completed with a VisibleString

and the Extended.

   The VisibleString allows the procedure/service to send any message in a

   text form;

   The extension allows the procedure/service to define any structure (This

   functionality will be required for the forward services).

 

=====

I looked at your alternative proposals:

NotificationTypes ::= CHOICE

{ notificationType ::= SEQUENCE

  {  eventName ParamEventOrListName

   , eventValue VisibleString

  }

, notificationTypeExtension Extended

}

This approach forces the procedure/service that needs additional parameter to

use the extension and does not allow the use of event name (including a

functional resource).

From my understanding that structure is not desirable.

 

The second alternative structures:

EventName ::= CHOICE

{ eventName ParamEventOrListName

, eventNameExtension Extended

}

 

EventValue ::= CHOICE

{ eventValue VisibleString

, eventValueExtension Extended

}

would again prevent the use of the agreed structured event name and from my

understanding is not desirable.

 

Please let me know if the replacement of CHOICE by SEQUENCE solves the issue.

 

I am not sure that I will have time before Christmas to work on the book

again and I will publish it with the above change. Additional changes will be

incorporated into the January 2012 version.

I will send a separate mail pointing to the uploaded file.

 

I wish you a merry Christmas with your family.

 

Best regards

Yves

 

 

 

                                                                                                                                   

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/css-csts/attachments/20120106/b343d624/attachment.html