[Css-csts] RE: Proposed Object Identifiers

Wed Nov 28 11:47:11 EST 2012

Yves,
My thoughts about using the extensionType node for something more than just TypeAndValue extensions was triggered by the proposed placement of the node under the general publishedIdentifiers node and not under CSTS. I thought that perhaps there was some discussion that I missed in Cleveland about why the extensionType OIDs might have a broader purpose, but from your answer that does not appear to be the case. In some sense, these extension types have "dual citizenship":  in one regard they belong to CSTS in that they only apply to the CSTS TypeAndValue type and have no more-general applicability; but in the other regard they are to be defined by CCSDS and/or individual Agencies outside of the Framework itself or the CSTS service specifications.  

My concern about the structure as you , Margherita, Colin, and Wolfgang have proposed it - a typeExtensions node under a cross support-level crossSupportResources node - is that the intended scope of the node (that is, that it is limited to the CSTS framework TypeAndValue type) is not at all evident  by its name, and the extensions really don't belong under the category of "resources".  

The attached  ProposedOidTree-121128 PPT is a variation of my original proposal  that the TypeAndValue extension identifiers be registered under the csts node, since they are confined to a CSTS Framework type. In this revised proposal, an externallyDefinedTypeAndValueExtensions node sits under the csts node. This node name and placement under csts clearly delimit the scope of the objects that are to be registered under this node. 
(Another variation would be to have an externallyDefinedIdentifiers node under the csts node, and under the externallyDefinedIdentifiers node is the typeAndValueExtensions node. Having the separate externallyDefinedIdentifiers node would allow for the possibility that we might discover other CSTS types that we would like to make externally-extensible. But given that we have not yet identified any such other types, the added complexity is probably not desirable).

Of course, as always these are just my observations and suggestions for what makes most sense to me. But if you do decide to keep the typeExtensions node outside of CSTS I have two other suggestions:
1.	Give the node a more descriptive/constrained name, such as cstsTypeAndValueExtensions, and
2. 	Don't place the type extension node under the crossSupportResources node, because it really doesn't fit that categorization. 

Best regards,
John

-----Original Message-----
From: Yves.Doat at esa.int [mailto:Yves.Doat at esa.int] 
Sent: Wednesday, November 28, 2012 2:36 AM
To: John Pietras
Cc: css-csts at mailman.ccsds.org
Subject: RE: Proposed Object Identifiers

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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ProposedOidTree-121128.pptx
Type: application/octet-stream
Size: 65593 bytes
Desc: ProposedOidTree-121128.pptx
Url : http://mailman.ccsds.org/pipermail/css-csts/attachments/20121128/6f4b0a51/ProposedOidTree-121128-0001.obj