<font size=2 face="sans-serif">Dear Igancio and all,</font>
<br>
<br><font size=2 face="sans-serif">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.</font>
<br>
<br><font size=2 face="sans-serif">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: </font><font size=2 color=#2f2f2f><b>Payload</b> in </font><a href=https://en.wikipedia.org/wiki/Computing><font size=2 color=#000080>computing</font></a><font size=2 color=#2f2f2f> (sometimes
referred to as the actual or body data) is the cargo of a </font><a href=https://en.wikipedia.org/wiki/Data_transmission><font size=2 color=#000080>data
transmission</font></a><font size=2 color=#2f2f2f>. It is the part of the
transmitted </font><a href=https://en.wikipedia.org/wiki/Data_(computing)><font size=2 color=#000080>data</font></a><font size=2 color=#2f2f2f> which
is the fundamental purpose of the transmission, to the exclusion of information
sent with it (such as </font><a href=https://en.wikipedia.org/wiki/Header_(computing)><font size=2 color=#000080>headers</font></a><font size=2 color=#2f2f2f> or</font><a href=https://en.wikipedia.org/wiki/Metadata><font size=2 color=#000080>metadata</font></a><font size=2 color=#2f2f2f>,
sometimes referred to as overhead data) solely to facilitate delivery</font><font size=3>.</font>
<br>
<br><font size=2 face="sans-serif">2) Regarding the inline comments:</font>
<br><font size=2 face="sans-serif">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.</font>
<br><font size=2 face="sans-serif">P 1-3: See payload discussion</font>
<br><font size=2 face="sans-serif">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.</font>
<br><font size=2 face="sans-serif">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. </font>
<br><font size=2 face="sans-serif">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.</font>
<br><font size=2 face="sans-serif">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.</font>
<br><font size=2 face="sans-serif">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. </font>
<br>
<br><font size=2 face="sans-serif">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?</font>
<br><font size=2 face="sans-serif"><br>
Cheers</font>
<br><font size=2 face="sans-serif">Daniel<br>
<br>
<br>
Dr. Daniel Fischer<br>
----------------------------<br>
Data Systems Manager<br>
Ground Systems Engineering Support Office<br>
Ground Systems Engineering Department<br>
Directorate of Human Spaceflight and Operations<br>
<br>
European Space Agency - ESOC<br>
Robert-Bosch-Str. 5<br>
D-64293 Darmstadt - Germany<br>
Tel: +49 (0) 6151 90 2718 - Fax: +49 (0) 6151 90 2718<br>
Web: </font><a href=http://www.esa.int/><font size=2 face="sans-serif">http://www.esa.int</font></a>
<br>
<br>
<br>
<br><font size=1 color=#5f5f5f face="sans-serif">From:
</font><font size=1 face="sans-serif">Ignacio.Aguilar.Sanchez@esa.int</font>
<br><font size=1 color=#5f5f5f face="sans-serif">To:
</font><font size=1 face="sans-serif">Moury Gilles <Gilles.Moury@cnes.fr>,
</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Cc:
</font><font size=1 face="sans-serif">"sls-sea-dls@mailman.ccsds.org"
<sls-sea-dls@mailman.ccsds.org></font>
<br><font size=1 color=#5f5f5f face="sans-serif">Date:
</font><font size=1 face="sans-serif">13/08/2015 13:35</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Subject:
</font><font size=1 face="sans-serif">Re: [Sls-sea-dls]
results of CESG poll for SDLS BB publication</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Sent by:
</font><font size=1 face="sans-serif">sls-sea-dls-bounces@mailman.ccsds.org</font>
<br>
<hr noshade>
<br>
<br>
<br><tt><font size=2>Dear Gilles and colleagues,<br>
<br>
I believe the comment from Tomaso, supported by Keith, is easy to deal
with<br>
the inclusion of such note.<br>
<br>
Concerning Peter's comments,<br>
<br>
1) We all agreed and supported harmonisation of the SDLS with the SLPs,
Part<br>
of the agreement was the assumption that the potential user shall start<br>
reading the SLPs before getting to the SDLS (since it is a NEW optional
SLP<br>
function). And we (SLP WG + SDLS WG) were very careful in deciding what
to<br>
put where. This can explain why the SDLS does not read so well stand-alone,<br>
as Peter seems to want.<br>
Including the three different scenarios (TC, TM, AOS) with corresponding<br>
drawings into the SDLS will substantially 'inflate' the introduction.<br>
And will risk causing incoherency issues with the SLPs and the still-to-be<br>
published SDLS Green Book.<br>
<br>
I think the issue needs to be re-discussed with Peter since the drawings
are<br>
already at the documents where they are supposed to be.<br>
<br>
2) The word 'payload' is mentioned 72 times in the document. The last mention<br>
is in paragraph B1.1, which is perhaps the one that I can see somewhat<br>
inconsistent but it should be easy to fix. Hence, I beg to disagree with<br>
Peter concerning inconsistency in its use. A different thing is whether<br>
another term could be used to avoid confusion with the classical meaning
of<br>
payload in space missions but I think the meaning in SDLS is pretty clear
and<br>
defined. On his proposals "package" looks too close to "packet"
and "user<br>
provided data" too close to "service data unit" (note that
the 'payload' as<br>
in SDLS context includes the SDU and something else, hence not a valid<br>
substitute).<br>
<br>
Unless someone finds a clear and unambiguous term to replace 'payload'
in the<br>
SDLS context, I would advocate to re-discuss the comment with Peter.<br>
<br>
<br>
3) If the document has to be self-standing concerning its interpretation,<br>
this is definitely a section that I think should stay. It is addressing
a<br>
core element of the SDLS. The Green Book will provide further elaboration
but<br>
a bare minimum is needed to be able to understand and interpret SDLS.<br>
<br>
4) There are three NOTES covering this issue that are consistent. I think
we<br>
did not want to impose requirements in this subject, reason why they are<br>
notes. But we could change it to requirements with the word 'may' to make<br>
them more visible as suggested by Peter.<br>
<br>
I hope the above helps.<br>
<br>
Kind regards,<br>
<br>
Ignacio<br>
<br>
<br>
<br>
From:
Moury Gilles <Gilles.Moury@cnes.fr><br>
To:
"sls-sea-dls@mailman.ccsds.org" <sls-sea-dls@mailman.ccsds.org><br>
Date:
13/08/2015 11:01<br>
Subject:
[Sls-sea-dls] results of CESG poll for SDLS BB publication<br>
Sent by:
sls-sea-dls-bounces@mailman.ccsds.org<br>
<br>
<br>
<br>
Dear CCSDS SDLS WG member,<br>
<br>
Please find attached 2 files:<br>
<br>
The results of the CESG poll (as of today – it terminates tomorrow)<br>
The commented version of the SDLS Blue Book attached to the comments of
Peter<br>
Shames (SEA AD)<br>
<br>
We have to respond to those comments and resolve them with the issuer before<br>
we can actually publish the BB. Please advise on the way to respond to
those<br>
comments.<br>
<br>
Best regards,<br>
<br>
Gilles MOURY<br>
SDLS WG Co-Chair<br>
=========================================================<br>
Gilles MOURY<br>
CNES Toulouse<br>
Expert
senior "Plateforme Satellite"<br>
Sous-Direction "Techniques Véhicule, Architecture
& Intégration"<br>
DCT/TV-RA - Bpi 1416<br>
18, avenue Edouard Belin<br>
F-31401 TOULOUSE Cedex 9<br>
</font></tt><a href=http://www.cnes.fr/><tt><font size=2>http://www.cnes.fr</font></tt></a><tt><font size=2><br>
tel : +33 (0)5 61 27 3790<br>
fax : +33 (0)5 61 27 4099<br>
sec : +33 (0)5 61 27 3882<br>
mob : +33 (0)6 83 56 0485<br>
=========================================================<br>
<br>
<br>
[attachment "results CESG SDLS BB poll.docx" deleted by Ignacio
Aguilar<br>
Sanchez/estec/ESA] [attachment "355x0b0_CESG_Approval-SEA.pdf"
deleted by<br>
Ignacio Aguilar Sanchez/estec/ESA]<br>
_______________________________________________<br>
SLS-SEA-DLS mailing list<br>
SLS-SEA-DLS@mailman.ccsds.org<br>
</font></tt><a href="http://mailman.ccsds.org/cgi-bin/mailman/listinfo/sls-sea-dls"><tt><font size=2>http://mailman.ccsds.org/cgi-bin/mailman/listinfo/sls-sea-dls</font></tt></a><tt><font size=2><br>
<br>
This message and any attachments are intended for the use of the addressee
or addressees only.<br>
The unauthorised disclosure, use, dissemination or copying (either in whole
or in part) of its<br>
content is not permitted.<br>
If you received this message in error, please notify the sender and delete
it from your system.<br>
Emails can be altered and their integrity cannot be guaranteed by the sender.<br>
<br>
Please consider the environment before printing this email.<br>
<br>
_______________________________________________<br>
SLS-SEA-DLS mailing list<br>
SLS-SEA-DLS@mailman.ccsds.org<br>
</font></tt><a href="http://mailman.ccsds.org/cgi-bin/mailman/listinfo/sls-sea-dls"><tt><font size=2>http://mailman.ccsds.org/cgi-bin/mailman/listinfo/sls-sea-dls</font></tt></a><tt><font size=2><br>
</font></tt>
<br><PRE>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.
</PRE>