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

Mon Jun 4 02:56:11 EDT 2012

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.