[Css-csts] Functional Resources and Object Identifiers -FrameworkUpdates

Wed Jun 6 16:31:00 EDT 2012

Yves,
I agree that casting the list names as Strings seems to be the best approach.

Regarding tying the list name to the "FR identifier" of the service. I don't see how a list name can be tied to a single instance of a service functional resource (e.g., Monitored Data provider instance #2) since by the way we have been discussing things, the instances of functional resources are actually assigned by Service Management in the process of scheduling the Service Package. That is , the service functional resource instances (or any FR instances, for that matter) don't exist until they are created by SM in the scheduling of the Service Package. Therefore the lists could not be pre-defined. 

It does seem reasonable to me to associate the list name with the service functional resource *type* (e.g., Monitored Data service provider).  If the lists (and their names) are mutually defined by the Complex and the Mission ahead of time, then any service instance of the specified type that is provided to that Mission by that Complex will be able to use any of the lists that are available for that service type. In that case, I think that the ASN.1 would look something like:

ListOfParameters ::= CHOICE
{     defaultList                 [0]       NULL
,     parameterNames   [1]      SEQUENCE OF  ParamOrEventListName
 ,    listName                     [2]      ListName 
}

-- The ParamOrEventName structure is used to identify:
-- 1. The name of a parameter
-- 2. The name of an event
ParamOrEventName ::= SEQUENCE
{   functionalResourceId   SEQUENCE
    {   functionalResourceType        PublishedIdentifier
    ,   functionalResourceInstance    INTEGER (1..MAX)
    }
,   paramOrEventId       PublishedIdentifier
      }

ListName ::= SEQUENCE
{   functionalResourceType        PublishedIdentifier
,   listDescriptor                               VisibleString
 }

I will be going on leave tomorrow (Thursday) about noon (Washington time), and won't be returning until 18 June. I will try to respond to any comments that I receive before noon tomorrow, but I won't be able to reply to comments received after that until I return.

Best regards,
John

-----Original Message-----
From: Yves.Doat at esa.int [mailto:Yves.Doat at esa.int] 
Sent: Monday, June 04, 2012 2:56 AM
To: John Pietras
Cc: css-csts at mailman.ccsds.org; css-csts-bounces at mailman.ccsds.org
Subject: RE: [Css-csts] Functional Resources and Object Identifiers -FrameworkUpdates

Dear John,

Of course you are fully correct, the ASN.1 is not in line with the definition. As stated previously, I have not yet updated the ASN.1 to reflect the new definitions. Based on this fact, I do not consider the ASN.1 to be used for driving the current specifications.

Your proposed ASN.1 is most probably in line with your statements. I will only start to look into the ASN.1 once our specifications are agreed.

I see two aspects in your argumentation:
   What do we use to represent a list name?
   Do we need a FR to be attached to the list name?

First aspect - List name representation.
We have several possibilities:
   Use of an OID. If we decide for an OID, then via SM the two Agencies
   deciding to use a service will have to allocate OID. Considering that OID
   are not to be created, deleted and reused, I do not think that approach
   suitable;
   String or Integer would provide the flexibility to each Agency when
   agreeing on using a service.
Based on the issue with OID, I propose to use a String. I know that they are not fully in line with other name definitions that are based on OID in the Framework but this looks to me the most convenient approach for our needs. In case you or someone else would prefer another definition please let me know.

Second aspect - FR usage:
In my proposal the list name when used is not attached to a FR. I do not have a strong opinion on that and we could easily state that a list name is attached to the FR and the instance of the service. That may be even cleaner as any identifier would be linked to a FR type and instance.
Please note that having read your comments and the text once more, I am convinced that the FR shall not be optional. In case we keep the FR optional, we will have to describe the behaviour when used and when not used. This option may be quite confusing for the implementers.
Following your mail, I will link the list name to the FR Identifier of the service.

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:       01/06/2012 17:29                                                                                                     

  Subject:    RE: [Css-csts] Functional Resources and Object Identifiers -	FrameworkUpdates                                   

  Sent by:    css-csts-bounces at mailman.ccsds.org                                                                                   

Yves,
I’ve now finally looked at your Implementation Scenario. The core of my concerns about list names is illustrated by the Note under the START Operation table in section 5.1.2 on page 9:
“NOTE   - The value of the list-of-parameters contains the string value ‘Space-Link Status’ and is not combined with any Object Identifiers.”

I actually like casting the list name as a string, but it is not consistent with the most-recently-released draft of the Framework. Throughout the 2012-ReturnServices draft version, the list name is described as “a parameter [or event list] identifier that represents multiple individual parameters [events], and (optionally) a Functional Resource identifier that represents the Functional Resource with which the specific instance of that parameter [event] list name is associated.”

In the ASN.1, the listName value of the ListOfParameters type is of type
ParamEventOrListName:

-- The ParamEventOrListName structure is used to identify:
-- 1. The name of a paramter[JP1]
-- 2. The name of an event
-- 3. The name of a list of parameters or events ParamEventOrListName ::= SEQUENCE {   functionalResource   CHOICE
    {   resourceIdApplicable [0] PublishedIdentifier
    ,   resourceIdNotApplicable [1] NULL
    }
,   paramEventOrListId PublishedIdentifier
      }

According to this definition,  the list name cannot take on a string value.
It must be a Published Identifier.

Note that the ASN.1 above does not reflect the change in which the functional resource ID is now composed of a [functional resource type : functional resource instance number ]pair.

With the proposal to remove the optional nature of the functional resource ID and the current definition of the functional resource ID, ParamEventOrListName (of which listName is an instance) is now specified as

ParamEventOrListName ::= SEQUENCE
{   functionalResourceId   SEQUENCE
    {   functionalResourceType        PublishedIdentifier
    ,   functionalResourceInstance    INTEGER (1..MAX)
    }
,   paramEventOrListId PublishedIdentifier
      }

According to this type definition, a list name has two Published Identifiers:
one as part of the functional resource ID, and the other as the ID of the list itself. My concern with not allowing the functional resource ID component of the list name to be null is that I don’t understand how we can in general associate a list with a single functional resource instance. The only option that I can see is to limit each list to contain parameters/events for a single functional resource instance, in which case an instance of the Monitored Data Service would have to START multiple instances of the Cyclic Report and Notification procedures in order to receive monitored parameters and event notification from multiple functional resource instances. Given the non-trivial number of functional resource instances possible in a service package, this seems like an unwelcome burden on the Mission.

Whether or not the functional resource ID is a mandatory part of the list name,  I have had concerns for some time now about the decision to make the “list ID” a published identifier. Whereas functional resource types and parameter/event types are intended to be used by multiple Agencies and Missions (or in the case of the Agency-unique registry, at least by all Missions that use an Agency’s resource), the list IDs seem to me to be unique to a single Mission-Agency (or Mission-Complex) association. Registering them in a repository like SANA seems to be overkill. They seem like something that should be mutually agreed at a Service Agreement type level.

For the above reasons, I actually like approach that you took in your Implementation Scenario note: to make the list names simple strings. As you have pointed out in the past, some rules will have to be established regarding case sensitivity, but overall I think that it will make list names much easier to deal with.

If the WG decides to go in this direction, I believe that the ASN.1 would look something like:

ListOfParameters ::= CHOICE
{ defaultList [0] NULL
, parameterNames [1] SEQUENCE OF ParamOrEventListName , listName [2] VisibleString }

-- The ParamOrEventName structure is used to identify:
-- 1. The name of a parameter
-- 2. The name of an event
ParamOrEventName ::= SEQUENCE
{   functionalResourceId   SEQUENCE
    {   functionalResourceType        PublishedIdentifier
    ,   functionalResourceInstance    INTEGER (1..MAX)
    }
,   paramOrEventId       PublishedIdentifier
      }

Best regards,
John

 [JP1]Typo in ASN.1_______________________________________________
Css-csts mailing list
Css-csts at mailman.ccsds.org
http://mailman.ccsds.org/cgi-bin/mailman/listinfo/css-csts

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.