[Sls-sea-dls] [SDLS Extended Procedures] TLV Format Question

Daniel.Fischer at esa.int Daniel.Fischer at esa.int
Thu Oct 15 12:53:02 UTC 2015


Hi Bruno

We can discuss in the meetings, but at least for (2) I think nested TLV 
would be an overkill. Key lengths will be the same within an OTAR uplink 
and thus the data field (V) spec that we have now (n times [KeyID, Key]) 
following the T and L fields is much more efficient. For the security log, 
we can discuss.

In my opinion, we should try to avoid nested TLV since it add another 
layer of complexity.

Cheers,
Daniel



Dr. Daniel Fischer
----------------------------
Data Systems Manager
Ground Segment Engineering Support Office (HSO-GE)
Ground Systems Engineering Department
Directorate of Human Spaceflight and Operations

European Space Agency - ESOC
Robert-Bosch-Str. 5
D-64293 Darmstadt - Germany
Tel: +49 (0) 6151 90 2718 - Fax: +49 (0) 6151 90 2718
Web: http://www.esa.int



From:   "Saba Bruno" <Bruno.Saba at cnes.fr>
To:     "Daniel.Fischer at esa.int" <Daniel.Fischer at esa.int>, 
"sls-sea-dls at mailman.ccsds.org" <sls-sea-dls at mailman.ccsds.org>
Date:   24/09/2015 15:40
Subject:        RE: [Sls-sea-dls] [SDLS Extended Procedures] TLV Format 
Question



Dear all,
 
In reply to Daniel?s question, I can see at least two use cases of nested 
TLV messages :
 
1)      Dump of the ?security log?, where the overall message complies 
with TLV format, with many embedded TLV messages inside (at least one per 
event),
2)      Key upload message (OTAR), each key being a TLV massage in itself.
 
Cheers,
 
 
Bruno Saba 
CNES 
DCT/TV/IN 
18 Avenue Edouard Belin 
31401 TOULOUSE Cedex 9 
Tel : + 33 (0) 5 61 28 28 76 
Fax : + 33 (0) 5 61 28 19 96 
 
 
De : sls-sea-dls-bounces at mailman.ccsds.org [
mailto:sls-sea-dls-bounces at mailman.ccsds.org] De la part de 
Daniel.Fischer at esa.int
Envoyé : jeudi 27 août 2015 09:55
À : sls-sea-dls at mailman.ccsds.org
Objet : [Sls-sea-dls] [SDLS Extended Procedures] TLV Format Question
 
Dear all, 

I am working on the update of the Extended Procedures book. 

One of the things agreed during the last meeting was to describe better 
the various possibilities of the TLV format. One of the items to be 
addressed in nested procedures. i.e. putting another TLV inside the value 
field. While I have no problem adding this to the spec, I am wondering if 
there is a use case for this in the scope of the Extended Procedures. 
Looking at the various proposed procedures, I could not find any. 

So if there is no use case for nesting in the scope of the book, do we 
really need to specify it? 

Cheers,
Daniel 



Dr. Daniel Fischer
----------------------------
Data Systems Manager
Ground Systems Engineering Support Office
Ground Systems Engineering Department
Directorate of Human Spaceflight and Operations

European Space Agency - ESOC
Robert-Bosch-Str. 5
D-64293 Darmstadt - Germany
Tel: +49 (0) 6151 90 2718 - Fax: +49 (0) 6151 90 2718
Web: http://www.esa.int
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 --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sls-sea-dls/attachments/20151015/fb60af69/attachment.html>


More information about the SLS-SEA-DLS mailing list