[Css-csts] RE: Proposed Object Identifiers

Wed Nov 28 02:36:21 EST 2012

Dear John,

With the current approach and the CSTS proposal, this new branch is only
foreseen for those complex types that cannot be defined using the current CST
ASN.1:
TypeAndValue			::=   CHOICE
{     integer                 [0]   SEQUENCE OF INTEGER
,     intUnsigned             [1]   SEQUENCE OF IntUnsigned
,     duration                [2]   SEQUENCE OF Duration
,     characterString         [3]   SEQUENCE OF VisibleString
,     boolean                 [4]   SEQUENCE OF BOOLEAN
,     octetString             [5]   SEQUENCE OF OCTET STRING
,     float                   [6]   SEQUENCE OF REAL
,     time                    [7]   SEQUENCE OF Time
,     enumerated              [8]   SEQUENCE OF IntUnsigned
,     valueExtension          [100] Extended
}
TypeAndValueComplexQualified	::=     CHOICE
{     typeAndValue            [0]   TypeAndValue
,     complexSequence         [1]   SEQUENCE OF TypeAndValue
,     complexSet              [2]   SET OF TypeAndValue
}

Your proposed approach would be that any parameter would have its own OID and
would not make use of the types definition in our ASN.1. I see 2 drawback to
that approach:
   As any parameter would have its own OID, we will end with different OID
   defining the same type;
   The number of OID to manage may become important;

As far as possible I would prefer to maintain the current approach and only
allow the definition of a different types for exceptional cases.

I can however understand that SM is interested by this flexibility and may be
you could better explain which usage would be proposed.

Best regards
Yves

  From:       John Pietras <john.pietras at gst.com>                                                                                  

  To:         <Margherita.di.Giulio at esa.int>, "Barkley, Erik J (3170)" <erik.j.barkley at jpl.nasa.gov>                               

  Cc:         <Colin.Haddow at esa.int>, <Wolfgang.Hell at esa.int>, <Yves.Doat at esa.int>                                                 

  Date:       16/11/2012 16:45                                                                                                     

  Subject:    RE: Proposed Object Identifiers                                                                                      

Margherita,
I have no objection to changing functionalResources to crossSupportResources.

Originally, I thought that the purpose of the  typeExtensions node is to
register extended type values (e.g., ‘complex’ might be a new type) for the
TypeAndValue type used by the QualifiedParameter type in CSTS. That is the
reason that I proposed keeping it under CSTS, and if it is used only in that
context then it somehow should stay in the context of CSTS.

However, thinking of it in a different way, “type” is something that goes
beyond CSTS, and in that sense dealing with type outside of CSTS makes sense,
and I’m guessing that is your motivation for putting it under the
crossSupportResources node. In particular, I can see how being able to add
types will help in the specification of parameter values for functional
resources (and now that I think of, I think that might have been explained in
Cleveland as the (or at least a) reason for allowing the type extensions).

So I agree in principle with moving the type “extensions” out from under
CSTS. But to be systematic and makes this as general-purpose as possible,
should we consider putting all types (including the ones already defined for
TypeAndValue) under this node? For example, when we get around to registering
in SANA a new monitored parameter that is of type “integer”, how will
“integer” be defined for that parameter? Will it be assumed to map into an
ASN.1 INTEGER, or should all monitored parameters  be defined in terms of one
(or more) explicitly-defined Integer type(s) outside just CSTS? I’m thinking
here of a case where an integer-valued  monitored parameter specification
might be used outside of CSTS (e.g., by service management).

I don’t remember if it was discussed in Cleveland where the current (base)
types of the CSTS TypeAndValue type are going to be redefined in terms of
OIDs. That would help to make the definition of parameters consistent: a new
parameter could be added to crossSupportFunctionalities and given a type as
an OID whether that type was defined as part of CSTS or as a new type. I
think that these types should be registered under the new type node because
they are types that have broader applicability than just CSTS.

Getting back to the original question (changing the location and name of the
node) – I agree that moving the node makes sense. However, the name
“typeExtensions” seems to tie it too closely to a single use – that is,
extending the TypeAndValue type of CSTS. I thing that a more-general name
like “dataTypeDefinitions” better represents to scope of the node.

Best regards,
John

From: Margherita.di.Giulio at esa.int [mailto:Margherita.di.Giulio at esa.int]
Sent: Friday, November 16, 2012 8:57 AM
To: Barkley, Erik J (3170)
Cc: Colin.Haddow at esa.int; John Pietras; Wolfgang.Hell at esa.int;
Yves.Doat at esa.int
Subject: Re: Proposed Object Identifiers

Dear Erik and John,

we have discussed your Object Identifiers tree, and would like to propose a
slight modification (see attachment) . Namely;

- in this approach also the typeExtensions are brought up to the general
level
- the "functionalResource" box has been given the generic name of
"crossSupportResources".

Please let us know your  opinion,
Kind regards,
Margherita

-------------------------------------------------------------
Margherita di Giulio
Ground Station Back-end Section (HSO-GIB)
European Space Agency ESA/ESOC
Robert-Bosch-Str. 5
D-64293 Darmstadt - Germany
Tel: +49-6151-902779
e-mail: Margherita.di.Giulio at esa.int

 From "Barkley, Erik J (3170)" <erik.j.barkley at jpl.nasa.gov>                 
 :                                                                           

 To:  "Margherita.di.Giulio at esa.int" <Margherita.di.Giulio at esa.int>, "       
      Yves.Doat at esa.int" <Yves.Doat at esa.int>                                 

 Cc:  "Colin.Haddow at esa.int" <Colin.Haddow at esa.int>, "Wolfgang.Hell at esa.int" 
      <Wolfgang.Hell at esa.int>, John Pietras <john.pietras at gst.com>           

 Date 10/11/2012 02:06                                                       
 :                                                                           

 Subj Proposed Object Identifiers                                            
 ect:                                                                        

Dear Margherita,  Yves,

Attached please find an updated Object Identifier Tree for your
consideration.  I believe you will find that it does no "harm" to the objects
identified in the previous version of the tree but does introduce a new layer
and move a couple categories to better position us for an overall object
identification tree for the CCSDS Cross Support Services Area.  And I believe
this is important as we are attempt to architect this for something that
would be applicable beyond just the CSTS working group. So in that regard,
here are the salient points:

The updated tree…

a.       Creates a cross support subtree that gives us a subspace to  work
within to identify major categories of future work that belong at the cross
support services level
1.       But it grandfathers in the existing SLE node directly under ccsds
(4) because it’s been there for nearly 20 years and is used operationally
b.      Keeps the existing structure under the CSTS node except
1.       It changes the node index from 4 to 1 and place it under cross
support (4));
2.       It moves the functions resource published identifiers
(crossSupportFunctionalities and agenciesFunctionalities) out from under CSTS
but keeps the typesExtensions node under CSTS/publishedIdentifiers (since
typeExtensions is specific to a CSTS-definedtype, QualifiedParameter).
a.       The rationale for moving the cross support functionalities and
agency functionalities is that they are not really part of the CSTS protocol
– for example, antennas, forward carriers, return carriers etc. are
functionalities represented in service management messages and are therefore
more properly identified at the  Cross Support Service area level.

It may be interesting to note that we may in fact have management object
identifiers that show up at the same level as the
crossSupportFunctionalities, etc. Therefore I believe that the revised tree
structure is a nice balance between allowing us to expand for the foreseeable
future but not getting lost in overly fine grain classification exercises.

May I ask that you please take a look and let me know if this is acceptable?

My thanks to John for working on this with me and providing the updated tree
and detailed insight.

Best regards,

-Erik

From: John Pietras [mailto:john.pietras at gst.com]
Sent: Friday, November 09, 2012 12:10 PM
To: Barkley, Erik J (3170)
Subject: Proposed revided OID tree

Erik,
Here it is. Salient points:
c.       It creates a cross support subtree that gives us a subspace to work
with within, except that it grandfathers in the existing SLE node directly
under ccsds (4) because it’s been there for nearly 20 years and is used
operationally
d.      It keeps the existing structure under the CSTS node except
1.       It changes the node index from 4 to 1 and place it under cross
support (4));
2.       It moves the functions resource published identifiers
(crossSupportFunctionalities and agenciesFunctionalities) out from under CSTS
but keeps the typesExtensions node under CSTS/publishedIdentifiers (since
typeExtensions is specific to a CSTS-definedtype, QualifiedParameter).

John

 [attachment "ProposedOidTree.pptx" deleted by Margherita di Giulio/esoc/ESA]
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.

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.