[Sls-sea-dls] results of CESG poll for SDLS BB publication

Thu Aug 13 12:50:59 UTC 2015

Dear Igancio and all,

I checked the comments as well. I agree to all you say below and I have a 
few more remarks/ first thoughts based on the comments that Peter put 
in-line in the document.

1) The word payload: While of course it has different meanings, the term 
"payload"  is very well established in the communication protocol world. 
You can find the following definition e.g. on Wikipedia: Payload in 
computing (sometimes referred to as the actual or body data) is the cargo 
of a data transmission. It is the part of the transmitted data which is 
the fundamental purpose of the transmission, to the exclusion of 
information sent with it (such as headers ormetadata, sometimes referred 
to as overhead data) solely to facilitate delivery.

2) Regarding the inline comments:
P 1-1: I am not sure about both comments. Is this section not a standard 
CCSDS section? It reads like one. If yes, I would not bother modifying it.
P 1-3: See payload discussion
P 2-1: I am not sure I understand the comment. We simply state that SDLS 
is not associated with any other protocol and as an example we bring the 
SPP. This may be a misunderstanding. Perhaps Peter confuses an association 
with another protocol (e.g. for extended procedures) with the concept of 
the underlying data-link layer protocol(s). If this causes too much 
discussion, we could even remove the note.
P 2-2: Following up on Ignacios comments, i would not include too much 
additional information here. We have the Green Book for that. Also, the 
other SLS books that have been updated mention SDLS and how it fits in as 
well. 
P 2-8: OK, I can see where he is coming from regarding the comment on the 
counter rollover. However, I think the note is pretty clear on this by 
saying the interpretation is mission-specific. We could think about being 
more concrete on this in the Green Book (if this is not already the case) 
and explain the benefits of not rolling over and how this can related to 
key lifetime.
P 3-7/3-10: I dont think that this section is an issue. Regarding the 
parameters, I think together with Section 6 (Managed Parameters) it makes 
sense to have them defined here. The only think that I agree may cause 
confusion is the paramater naming. E.g: Section 3.4.2.2 says 
"SA_authentication_key" while Section 6 says "Authentication Key". Maybe 
we could add a column to the table on Section 6, referring to the names 
used in Section 3.4.2.2. Regarding Section 3.4.3, I would almost be 
tempted to remove the Section from the standard (it is empty and the note 
will be out of date once the extended procedures...which are not a 
"revision" of the SDLS standard, but an addon...are out. We could pick 
this up in the Green Book.
P 6-1: (1) Not sure why we should add "unspecified". Did he want to say 
st. like "not covered by this standard?"...TBD (2) The SA database is not 
abstract. In fact it has to be very concrete if you want to do an 
implementation. Our prototype has one. 

3) I think we should seek to have telcon with Peter not too far in the 
future to discuss his comments and not wait three months for the next 
meetings. This way, we could speed up the publication process a bit. What 
do you think?

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

From:   Ignacio.Aguilar.Sanchez at esa.int
To:     Moury Gilles <Gilles.Moury at cnes.fr>, 
Cc:     "sls-sea-dls at mailman.ccsds.org" <sls-sea-dls at mailman.ccsds.org>
Date:   13/08/2015 13:35
Subject:        Re: [Sls-sea-dls] results of CESG poll for SDLS BB 
publication
Sent by:        sls-sea-dls-bounces at mailman.ccsds.org

Dear Gilles and colleagues,

I believe the comment from Tomaso, supported by Keith, is easy to deal 
with
the inclusion of such note.

Concerning Peter's comments,

1) We all agreed and supported harmonisation of the SDLS with the SLPs, 
Part
of the agreement was the assumption that the potential user shall start
reading the SLPs before getting to the SDLS (since it is a NEW optional 
SLP
function). And we (SLP WG + SDLS WG) were very careful in deciding what to
put where. This can explain why the SDLS does not read so well 
stand-alone,
as Peter seems to want.
Including the three different scenarios (TC, TM, AOS) with corresponding
drawings into the SDLS will substantially  'inflate' the introduction.
 And will risk causing incoherency issues with the SLPs and the 
still-to-be
published SDLS Green Book.

I think the issue needs to be re-discussed with Peter since the drawings 
are
already at the documents where they are supposed to be.

2) The word 'payload' is mentioned 72 times in the document. The last 
mention
is in paragraph B1.1, which is perhaps the one that I can see somewhat
inconsistent but it should be easy to fix. Hence, I beg to disagree with
Peter concerning inconsistency in its use. A different thing is whether
another term could be used to avoid confusion with the classical meaning 
of
payload in space missions but I think the meaning in SDLS is pretty clear 
and
defined. On his proposals "package" looks too close to "packet" and "user
provided data" too close to "service data unit" (note that the 'payload' 
as
in SDLS context includes the SDU and something else, hence not a valid
substitute).

Unless someone finds a clear and unambiguous term to replace 'payload' in 
the
SDLS context, I would advocate to re-discuss the comment with Peter.

3) If the document has to be self-standing concerning its interpretation,
this is definitely a section that I think should stay. It is addressing a
core element of the SDLS. The Green Book will provide further elaboration 
but
a bare minimum is needed to be able to understand and interpret SDLS.

4) There are three NOTES covering this issue that are consistent. I think 
we
did not want to impose requirements in this subject, reason why they are
notes. But we could change it to requirements with the word 'may' to make
them more visible as suggested by Peter.

I hope the above helps.

Kind regards,

Ignacio

From:            Moury Gilles <Gilles.Moury at cnes.fr>
To:              "sls-sea-dls at mailman.ccsds.org" 
<sls-sea-dls at mailman.ccsds.org>
Date:            13/08/2015 11:01
Subject:                 [Sls-sea-dls] results of CESG poll for SDLS BB 
publication
Sent by:                 sls-sea-dls-bounces at mailman.ccsds.org

Dear CCSDS SDLS WG member,

Please find attached 2 files:

The results of the CESG poll (as of today ? it terminates tomorrow)
The commented version of the SDLS Blue Book attached to the comments of 
Peter
Shames (SEA AD)

We have to respond to those comments and resolve them with the issuer 
before
we can actually publish the BB. Please advise on the way to respond to 
those
comments.

Best regards,

Gilles MOURY
SDLS WG Co-Chair
          =========================================================
                                Gilles MOURY
                                CNES Toulouse
                    Expert senior "Plateforme Satellite"
      Sous-Direction "Techniques Véhicule, Architecture & Intégration"
                           DCT/TV-RA  -  Bpi 1416
                          18, avenue Edouard Belin
                          F-31401 TOULOUSE Cedex 9
                             http://www.cnes.fr
                          tel : +33 (0)5 61 27 3790
                          fax : +33 (0)5 61 27 4099
                          sec : +33 (0)5 61 27 3882
                          mob : +33 (0)6 83 56 0485
          =========================================================

 [attachment "results CESG SDLS BB poll.docx" deleted by Ignacio Aguilar
Sanchez/estec/ESA] [attachment "355x0b0_CESG_Approval-SEA.pdf" deleted by
Ignacio Aguilar Sanchez/estec/ESA]
_______________________________________________
SLS-SEA-DLS mailing list
SLS-SEA-DLS at mailman.ccsds.org
http://mailman.ccsds.org/cgi-bin/mailman/listinfo/sls-sea-dls

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.

_______________________________________________
SLS-SEA-DLS mailing list
SLS-SEA-DLS at mailman.ccsds.org
http://mailman.ccsds.org/cgi-bin/mailman/listinfo/sls-sea-dls

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/20150813/f1577eda/attachment.html>