[Css-csts] keep services and Framework separate

[Yves.Doat at esa.int]

Dear Time,
Your proposal is very sensible.
The ASN.1 definition of the OID for the services should be outside the
Framework and the tree should ultimately be also under configuration control
outside the Framework.
I will remove the services ASN.1 OID definition from the Framework (not for
your prototype) and keep them for the time being in the tree inside the
Framework.

Please find attached the OID tree that is under preparation and reflects the
ASN.1 I delivered early September. Let me know if you find discrepancies.
(See attached file: OID 20090903.xls)
Best regards
Yves DOAT
__________________________________________________
Head of the Stations and M&C Integration Section (OPS-GSI)
ESA/ESOC Robert-Bosch Strasse 5
D-64293 Darmstadt, Germany
Tel.: +49 (6151) 90.2288               Fax:+49 (6151) 90.3046
Internet: http://www.esa.int/
__________________________________________________



                                                                             
             "Ray, Timothy J.                                                
             (GSFC-5830)"                                                    
             <timothy.j.ray at nas                                           To 
             a.gov>                     "css-csts at mailman.ccsds.org"         
             Sent by:                   <css-csts at mailman.ccsds.org>         
             css-csts-bounces at m                                           cc 
             ailman.ccsds.org                                                
                                                                     Subject 
                                        [Css-csts] keep services and         
             09/09/2009 22:50           Framework separate                   
                                                                             
                                                                             
                                                                             
                                                                             
                                                                             
                                                                             




Dear WG,

It seems sensible to keep Service-level specifications separate from our
Framework specification.  Benefits of this approach include being able to add
a new service (or modify an existing service) without modifying the Framework
specification.  Here are some examples of Service-level specification that
are in version 0.19 of our Framework specification – these examples are all
in the appendices that define ASN.1:

Page C-7:
--PROTOTYPES SERVICES OBJECT IDENTIFIERS
protoIdentifiers   OBJECT IDENTIFIER ::= {framework 1}
Note:  I think it makes sense to *keep* the ‘servicesIdentifiers’ object
because it serves as the root of all services.
Note:  I think the ‘protoIdentifiers’ can be kept

Pages D-11 through D-12:
D2.2 SERVICE TYPE IDENTIFIERS
(this whole section)

I suggest that we define each service’s object-identifier values within the
specification for that service.

(Please forgive me if this idea has already been discussed and decided.)

Best regards,
Tim


 _______________________________________________
Css-csts mailing list
Css-csts at mailman.ccsds.org
http://mailman.ccsds.org/cgi-bin/mailman/listinfo/css-csts
-------------- next part --------------
A non-text attachment was scrubbed...
Name: =?UTF-8?B?T0lEIDIwMDkwOTAzLnhscw==?=
Type: application/msexcel
Size: 35840 bytes
Desc: not available
Url : http://mailman.ccsds.org/pipermail/css-csts/attachments/20090910/c655c64d/UTF-8BT0lEIDIwMDkwOTAzLnhscw-0001.bin