From Gilles.Moury at cnes.fr Thu Aug 13 08:59:03 2015 From: Gilles.Moury at cnes.fr (Moury Gilles) Date: Thu, 13 Aug 2015 08:59:03 +0000 Subject: [Sls-sea-dls] results of CESG poll for SDLS BB publication Message-ID: <442F062EBF46F247A96B8A50EF3EB6F417043F02@TW-MBX-P04.cnesnet.ad.cnes.fr> 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 ========================================================= -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: results CESG SDLS BB poll.docx Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document Size: 339866 bytes Desc: results CESG SDLS BB poll.docx URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 355x0b0_CESG_Approval-SEA.pdf Type: application/pdf Size: 1067847 bytes Desc: 355x0b0_CESG_Approval-SEA.pdf URL: From Ignacio.Aguilar.Sanchez at esa.int Thu Aug 13 11:32:06 2015 From: Ignacio.Aguilar.Sanchez at esa.int (Ignacio.Aguilar.Sanchez at esa.int) Date: Thu, 13 Aug 2015 13:32:06 +0200 Subject: [Sls-sea-dls] results of CESG poll for SDLS BB publication In-Reply-To: <442F062EBF46F247A96B8A50EF3EB6F417043F02@TW-MBX-P04.cnesnet.ad.cnes.fr> References: <442F062EBF46F247A96B8A50EF3EB6F417043F02@TW-MBX-P04.cnesnet.ad.cnes.fr> Message-ID: <17595_1439465714_55CC80F2_17595_35_2_OF6EBC019A.596F807F-ONC1257EA0.0033E2AF-C1257EA0.003F5CEE@esa.int> 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 To: "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. From Daniel.Fischer at esa.int Thu Aug 13 12:50:59 2015 From: Daniel.Fischer at esa.int (Daniel.Fischer at esa.int) Date: Thu, 13 Aug 2015 14:50:59 +0200 Subject: [Sls-sea-dls] results of CESG poll for SDLS BB publication In-Reply-To: <17595_1439465714_55CC80F2_17595_35_2_OF6EBC019A.596F807F-ONC1257EA0.0033E2AF-C1257EA0.003F5CEE@esa.int> References: <442F062EBF46F247A96B8A50EF3EB6F417043F02@TW-MBX-P04.cnesnet.ad.cnes.fr> <17595_1439465714_55CC80F2_17595_35_2_OF6EBC019A.596F807F-ONC1257EA0.0033E2AF-C1257EA0.003F5CEE@esa.int> Message-ID: <11307_1439470258_55CC92B2_11307_216_1_OFE2A6AFE7.6E8CCB1B-ONC1257EA0.0042AA00-C1257EA0.0046943D@esa.int> 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 , Cc: "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 To: "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: From Gilles.Moury at cnes.fr Wed Aug 19 13:44:48 2015 From: Gilles.Moury at cnes.fr (Moury Gilles) Date: Wed, 19 Aug 2015 13:44:48 +0000 Subject: [Sls-sea-dls] results of CESG poll for SDLS BB publication In-Reply-To: <11307_1439470258_55CC92B2_11307_216_1_OFE2A6AFE7.6E8CCB1B-ONC1257EA0.0042AA00-C1257EA0.0046943D@esa.int> References: <442F062EBF46F247A96B8A50EF3EB6F417043F02@TW-MBX-P04.cnesnet.ad.cnes.fr> <17595_1439465714_55CC80F2_17595_35_2_OF6EBC019A.596F807F-ONC1257EA0.0033E2AF-C1257EA0.003F5CEE@esa.int> <11307_1439470258_55CC92B2_11307_216_1_OFE2A6AFE7.6E8CCB1B-ONC1257EA0.0042AA00-C1257EA0.0046943D@esa.int> Message-ID: <442F062EBF46F247A96B8A50EF3EB6F417048C93@TW-MBX-P04.cnesnet.ad.cnes.fr> Dear Daniel, Ignacio and SDLS WG members, I concur with Ignacio and Daniel proposals for Peter's comments disposition. More specifically, taking Peter's comments one by one (I attach Peter's commented version for reference): P 1-1 : OK for the 2 comments P 1-3, 3-1 : The usage of the term Payload: this term is duly defined upfront in SDLS book and therefore this definition replaces the CCSDS generic definition in the context of SDLS. The term is used consistently throughout the document. Besides the term payload is widely used with that meaning in the COMSEC domain. I agree with Ignacio and Daniel that we should discuss this with Peter and advocate for keeping this term. P 2-1 : Comment not understood. To be discussed with Peter. In any case we can remove the parenthesis in the note if that causes problem. P 2-2 : I do not support inserting in SDLS a duplicate of figures 6-1 of TM, TC and AOS books, but we could simply refer/point to it respectively in sections 2.2.3, 2.2.4 and 2.2.5 with a statement like: "the structure of the TM/TC/AOS Transfer Frame with SDLS is given in Figure 6-1 of [1]/[2]/[3]. This statement could also be placed once in section 2.3.1.4 Security Header and Trailer. P 2-5 : Figure 2-4 : we need to change A and B to AOS ApplySecurity payload or return (instead of TM ApplySecurity ...) P2-8, 4-9, 4-12 : NOTE on sequence number rollover : I would suggest keeping the NOTE but limiting it to the first sentence (The interpretation of a sequence number rollover (to zero) is mission specific) and then pointing to a specific SDLS green book subsection where this is discussed in more details. This would avoid confusion for implementers making it clear there is no specific recommendation (should) or permission (may) for that subject in the Blue Book. P 3-7, 3-10 : SA management service: I would propose keeping subsection 3.4.2 intact (SA management service parameters). Replace the NOTE in 3.4.3 (SA management service directives) by : "The directives for SA management will be specified in a CCSDS recommendation currently under development (355.1-B: SDLS extended procedures)." To be coherent with that, I would replace the second sentence of subsection 3.4.1 by: "The service directives necessary to manage the SA parameters will be specified in a CCSDS recommendation currently under development (355.1-B: SDLS extended procedures)". As suggested by Daniel, we could add a column in table 6-1 to indicate the correspondence between parameters denomination in subsection 3.4.2 and in Table 6-1. P 5-1: Peters comment: (no mention of payload in that section 5 "Use of the services with CCSDS protocols"). I would propose to show the "ApplySecurity payload" in figures 5-1 (TM transfer frame), 5-2 (TC), 5-3 (AOS). P 6-1 : OK to add unspecified (an unspecified management system). For the second comment (abstract SA data base) I tend to agree with Daniel, the SA data base is not abstract . It has to be implemented both on-ground and on-board. P B-1 : OK to replace "user-supplied data unit" by "transfer frame data field" to make it unambiguous. I hope we can converge with Peter on commonly agreed dispositions. We need to consolidate first our WG responses to his comments. Craig : let us know your position wrt the comments, so we can produce a redline version of the document with our proposed dispositions and associated explanations inserted. Best regards, Gilles Gilles MOURY CNES Toulouse De : Daniel.Fischer at esa.int [mailto:Daniel.Fischer at esa.int] Envoyé : jeudi 13 août 2015 14:51 À : Ignacio.Aguilar.Sanchez at esa.int Cc : Moury Gilles; sls-sea-dls at mailman.ccsds.org; sls-sea-dls-bounces at mailman.ccsds.org Objet : Re: [Sls-sea-dls] results of CESG poll for SDLS BB publication 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 >, Cc: "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 > To: "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: -------------- next part -------------- A non-text attachment was scrubbed... Name: 355x0b0_CESG_Approval-SEA.pdf Type: application/pdf Size: 1147359 bytes Desc: 355x0b0_CESG_Approval-SEA.pdf URL: From Gilles.Moury at cnes.fr Fri Aug 21 16:06:48 2015 From: Gilles.Moury at cnes.fr (Moury Gilles) Date: Fri, 21 Aug 2015 16:06:48 +0000 Subject: [Sls-sea-dls] SDLS BB : proposal for PS comments dispositions Message-ID: <442F062EBF46F247A96B8A50EF3EB6F417049E7A@TW-MBX-P04.cnesnet.ad.cnes.fr> Dear SDLS WG members, Please find attached a redline version of the SDLS BB with proposed dispositions for Peter Shames comments (in line with my herebelow mail). The text modifications are tentatively justified wrt Peter's comment. We should converge internally to the WG before sending the proposed redline to Peter Shames. Craig, as technical editor of the book, could you please take the lead on this ? I am leaving for one week so will not be able to make any progress. Best regards, Gilles Gilles MOURY SDLS WG Co-Chair De : sls-sea-dls-bounces at mailman.ccsds.org [mailto:sls-sea-dls-bounces at mailman.ccsds.org] De la part de Moury Gilles Envoyé : mercredi 19 août 2015 15:45 À : Daniel.Fischer at esa.int; Ignacio.Aguilar.Sanchez at esa.int Cc : sls-sea-dls at mailman.ccsds.org; sls-sea-dls-bounces at mailman.ccsds.org Objet : RE: [Sls-sea-dls] results of CESG poll for SDLS BB publication Dear Daniel, Ignacio and SDLS WG members, I concur with Ignacio and Daniel proposals for Peter's comments disposition. More specifically, taking Peter's comments one by one (I attach Peter's commented version for reference): P 1-1 : OK for the 2 comments P 1-3, 3-1 : The usage of the term Payload: this term is duly defined upfront in SDLS book and therefore this definition replaces the CCSDS generic definition in the context of SDLS. The term is used consistently throughout the document. Besides the term payload is widely used with that meaning in the COMSEC domain. I agree with Ignacio and Daniel that we should discuss this with Peter and advocate for keeping this term. P 2-1 : Comment not understood. To be discussed with Peter. In any case we can remove the parenthesis in the note if that causes problem. P 2-2 : I do not support inserting in SDLS a duplicate of figures 6-1 of TM, TC and AOS books, but we could simply refer/point to it respectively in sections 2.2.3, 2.2.4 and 2.2.5 with a statement like: "the structure of the TM/TC/AOS Transfer Frame with SDLS is given in Figure 6-1 of [1]/[2]/[3]. This statement could also be placed once in section 2.3.1.4 Security Header and Trailer. P 2-5 : Figure 2-4 : we need to change A and B to AOS ApplySecurity payload or return (instead of TM ApplySecurity ...) P2-8, 4-9, 4-12 : NOTE on sequence number rollover : I would suggest keeping the NOTE but limiting it to the first sentence (The interpretation of a sequence number rollover (to zero) is mission specific) and then pointing to a specific SDLS green book subsection where this is discussed in more details. This would avoid confusion for implementers making it clear there is no specific recommendation (should) or permission (may) for that subject in the Blue Book. P 3-7, 3-10 : SA management service: I would propose keeping subsection 3.4.2 intact (SA management service parameters). Replace the NOTE in 3.4.3 (SA management service directives) by : "The directives for SA management will be specified in a CCSDS recommendation currently under development (355.1-B: SDLS extended procedures)." To be coherent with that, I would replace the second sentence of subsection 3.4.1 by: "The service directives necessary to manage the SA parameters will be specified in a CCSDS recommendation currently under development (355.1-B: SDLS extended procedures)". As suggested by Daniel, we could add a column in table 6-1 to indicate the correspondence between parameters denomination in subsection 3.4.2 and in Table 6-1. P 5-1: Peters comment: (no mention of payload in that section 5 "Use of the services with CCSDS protocols"). I would propose to show the "ApplySecurity payload" in figures 5-1 (TM transfer frame), 5-2 (TC), 5-3 (AOS). P 6-1 : OK to add unspecified (an unspecified management system). For the second comment (abstract SA data base) I tend to agree with Daniel, the SA data base is not abstract . It has to be implemented both on-ground and on-board. P B-1 : OK to replace "user-supplied data unit" by "transfer frame data field" to make it unambiguous. I hope we can converge with Peter on commonly agreed dispositions. We need to consolidate first our WG responses to his comments. Craig : let us know your position wrt the comments, so we can produce a redline version of the document with our proposed dispositions and associated explanations inserted. Best regards, Gilles Gilles MOURY CNES Toulouse De : Daniel.Fischer at esa.int [mailto:Daniel.Fischer at esa.int] Envoyé : jeudi 13 août 2015 14:51 À : Ignacio.Aguilar.Sanchez at esa.int Cc : Moury Gilles; sls-sea-dls at mailman.ccsds.org; sls-sea-dls-bounces at mailman.ccsds.org Objet : Re: [Sls-sea-dls] results of CESG poll for SDLS BB publication 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 >, Cc: "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 > To: "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: -------------- next part -------------- A non-text attachment was scrubbed... Name: 355x0b0_CESG_Approval with CESG comments dispositions.doc Type: application/msword Size: 739840 bytes Desc: 355x0b0_CESG_Approval with CESG comments dispositions.doc URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 355x0b0_CESG_Approval-SEA.pdf Type: application/pdf Size: 1147359 bytes Desc: 355x0b0_CESG_Approval-SEA.pdf URL: From craig.biggerstaff at nasa.gov Fri Aug 21 20:54:10 2015 From: craig.biggerstaff at nasa.gov (Biggerstaff, Craig (JSC-CD221)[LOCKHEED MARTIN CORP]) Date: Fri, 21 Aug 2015 20:54:10 +0000 Subject: [Sls-sea-dls] RE: SDLS BB : proposal for PS comments dispositions In-Reply-To: <442F062EBF46F247A96B8A50EF3EB6F417049E7A@TW-MBX-P04.cnesnet.ad.cnes.fr> References: <442F062EBF46F247A96B8A50EF3EB6F417049E7A@TW-MBX-P04.cnesnet.ad.cnes.fr> Message-ID: <321CDC5F015F3B418419F05A79B668BA18DC0A1B@NDJSMBX101.ndc.nasa.gov> Dear WG members, Gilles, thank you for adding in the proposed dispositions for Peter Shames. I have added the NOTE to section 1.1 to answer Tomaso de Cola's and Keith Scott's conditions, updated figures 2-4,5-1,5-2,5-3, and made one or two minor alterations to the proposed language to avoid an implicit dependency of 355.0 upon 355.1. If these changes meet with the WG's satisfaction, I will forward them to Peter for his review and cc Tom Gannett per the conditional approval procedures. Best regards, Craig From: Moury Gilles [mailto:Gilles.Moury at cnes.fr] Sent: Friday, August 21, 2015 11:07 AM To: Biggerstaff, Craig (JSC-CD221)[LOCKHEED MARTIN CORP]; Ignacio.Aguilar.Sanchez at esa.int; Daniel.Fischer at esa.int; howie.weiss at sparta.com Cc: sls-sea-dls at mailman.ccsds.org; sls-sea-dls-bounces at mailman.ccsds.org Subject: SDLS BB : proposal for PS comments dispositions Dear SDLS WG members, Please find attached a redline version of the SDLS BB with proposed dispositions for Peter Shames comments (in line with my herebelow mail). The text modifications are tentatively justified wrt Peter's comment. We should converge internally to the WG before sending the proposed redline to Peter Shames. Craig, as technical editor of the book, could you please take the lead on this ? I am leaving for one week so will not be able to make any progress. Best regards, Gilles Gilles MOURY SDLS WG Co-Chair De : sls-sea-dls-bounces at mailman.ccsds.org [mailto:sls-sea-dls-bounces at mailman.ccsds.org] De la part de Moury Gilles Envoyé : mercredi 19 août 2015 15:45 À : Daniel.Fischer at esa.int; Ignacio.Aguilar.Sanchez at esa.int Cc : sls-sea-dls at mailman.ccsds.org; sls-sea-dls-bounces at mailman.ccsds.org Objet : RE: [Sls-sea-dls] results of CESG poll for SDLS BB publication Dear Daniel, Ignacio and SDLS WG members, I concur with Ignacio and Daniel proposals for Peter's comments disposition. More specifically, taking Peter's comments one by one (I attach Peter's commented version for reference): P 1-1 : OK for the 2 comments P 1-3, 3-1 : The usage of the term Payload: this term is duly defined upfront in SDLS book and therefore this definition replaces the CCSDS generic definition in the context of SDLS. The term is used consistently throughout the document. Besides the term payload is widely used with that meaning in the COMSEC domain. I agree with Ignacio and Daniel that we should discuss this with Peter and advocate for keeping this term. P 2-1 : Comment not understood. To be discussed with Peter. In any case we can remove the parenthesis in the note if that causes problem. P 2-2 : I do not support inserting in SDLS a duplicate of figures 6-1 of TM, TC and AOS books, but we could simply refer/point to it respectively in sections 2.2.3, 2.2.4 and 2.2.5 with a statement like: "the structure of the TM/TC/AOS Transfer Frame with SDLS is given in Figure 6-1 of [1]/[2]/[3]. This statement could also be placed once in section 2.3.1.4 Security Header and Trailer. P 2-5 : Figure 2-4 : we need to change A and B to AOS ApplySecurity payload or return (instead of TM ApplySecurity ...) P2-8, 4-9, 4-12 : NOTE on sequence number rollover : I would suggest keeping the NOTE but limiting it to the first sentence (The interpretation of a sequence number rollover (to zero) is mission specific) and then pointing to a specific SDLS green book subsection where this is discussed in more details. This would avoid confusion for implementers making it clear there is no specific recommendation (should) or permission (may) for that subject in the Blue Book. P 3-7, 3-10 : SA management service: I would propose keeping subsection 3.4.2 intact (SA management service parameters). Replace the NOTE in 3.4.3 (SA management service directives) by : "The directives for SA management will be specified in a CCSDS recommendation currently under development (355.1-B: SDLS extended procedures)." To be coherent with that, I would replace the second sentence of subsection 3.4.1 by: "The service directives necessary to manage the SA parameters will be specified in a CCSDS recommendation currently under development (355.1-B: SDLS extended procedures)". As suggested by Daniel, we could add a column in table 6-1 to indicate the correspondence between parameters denomination in subsection 3.4.2 and in Table 6-1. P 5-1: Peters comment: (no mention of payload in that section 5 "Use of the services with CCSDS protocols"). I would propose to show the "ApplySecurity payload" in figures 5-1 (TM transfer frame), 5-2 (TC), 5-3 (AOS). P 6-1 : OK to add unspecified (an unspecified management system). For the second comment (abstract SA data base) I tend to agree with Daniel, the SA data base is not abstract . It has to be implemented both on-ground and on-board. P B-1 : OK to replace "user-supplied data unit" by "transfer frame data field" to make it unambiguous. I hope we can converge with Peter on commonly agreed dispositions. We need to consolidate first our WG responses to his comments. Craig : let us know your position wrt the comments, so we can produce a redline version of the document with our proposed dispositions and associated explanations inserted. Best regards, Gilles Gilles MOURY CNES Toulouse De : Daniel.Fischer at esa.int [mailto:Daniel.Fischer at esa.int] Envoyé : jeudi 13 août 2015 14:51 À : Ignacio.Aguilar.Sanchez at esa.int Cc : Moury Gilles; sls-sea-dls at mailman.ccsds.org; sls-sea-dls-bounces at mailman.ccsds.org Objet : Re: [Sls-sea-dls] results of CESG poll for SDLS BB publication 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 >, Cc: "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 > To: "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: -------------- next part -------------- A non-text attachment was scrubbed... Name: 355x0b0_CESG_Approval with CESG comments dispositions 2.doc Type: application/msword Size: 830464 bytes Desc: 355x0b0_CESG_Approval with CESG comments dispositions 2.doc URL: From Ignacio.Aguilar.Sanchez at esa.int Mon Aug 24 08:00:37 2015 From: Ignacio.Aguilar.Sanchez at esa.int (Ignacio.Aguilar.Sanchez at esa.int) Date: Mon, 24 Aug 2015 10:00:37 +0200 Subject: [Sls-sea-dls] RE: SDLS BB : proposal for PS comments dispositions In-Reply-To: <321CDC5F015F3B418419F05A79B668BA18DC0A1B@NDJSMBX101.ndc.nasa.gov> References: <442F062EBF46F247A96B8A50EF3EB6F417049E7A@TW-MBX-P04.cnesnet.ad.cnes.fr> <321CDC5F015F3B418419F05A79B668BA18DC0A1B@NDJSMBX101.ndc.nasa.gov> Message-ID: <19395_1440403239_55DACF27_19395_1815_1_OF98786F27.D75C8F77-ONC1257EAB.002AADE3-C1257EAB.002C0079@esa.int> Dear Craig et al, The proposed update as well as the responses to Peter's comments are almost fine with me. My only problem is adding the word 'unspecified' before 'management' in section 6.1. This language is not consistent with the language used with the TC, TM and AOS BBs. We have attempted to harmonise the four standards to the best of our ability. Either we state everywhere that the management is not specified or we do not. And we do it in the same way. To be clear, each of the four standards contains a statement in section 1.2 where the absence of specification for the management activities is stated. The word 'unspecified' does not show up a single time in TC, TM and AOS BBs. In order to avoid additional modifications on TC, TM and AOS BBs to achieve full consistency with this topic, I would propose to remove the word 'unspecified'. Kind regards, Ignacio From: "Biggerstaff, Craig (JSC-CD221)[LOCKHEED MARTIN CORP]" To: "Moury Gilles" , "Ignacio.Aguilar.Sanchez at esa.int" , "Daniel.Fischer at esa.int" , "howie.weiss at sparta.com" Cc: "sls-sea-dls at mailman.ccsds.org" Date: 21/08/2015 22:55 Subject: [Sls-sea-dls] RE: SDLS BB : proposal for PS comments dispositions Sent by: sls-sea-dls-bounces at mailman.ccsds.org Dear WG members, Gilles, thank you for adding in the proposed dispositions for Peter Shames. I have added the NOTE to section 1.1 to answer Tomaso de Cola’s and Keith Scott’s conditions, updated figures 2-4,5-1,5-2,5-3, and made one or two minor alterations to the proposed language to avoid an implicit dependency of 355.0 upon 355.1. If these changes meet with the WG’s satisfaction, I will forward them to Peter for his review and cc Tom Gannett per the conditional approval procedures. Best regards, Craig From: Moury Gilles [mailto:Gilles.Moury at cnes.fr] Sent: Friday, August 21, 2015 11:07 AM To: Biggerstaff, Craig (JSC-CD221)[LOCKHEED MARTIN CORP]; Ignacio.Aguilar.Sanchez at esa.int; Daniel.Fischer at esa.int; howie.weiss at sparta.com Cc: sls-sea-dls at mailman.ccsds.org; sls-sea-dls-bounces at mailman.ccsds.org Subject: SDLS BB : proposal for PS comments dispositions Dear SDLS WG members, Please find attached a redline version of the SDLS BB with proposed dispositions for Peter Shames comments (in line with my herebelow mail). The text modifications are tentatively justified wrt Peter’s comment. We should converge internally to the WG before sending the proposed redline to Peter Shames. Craig, as technical editor of the book, could you please take the lead on this ? I am leaving for one week so will not be able to make any progress. Best regards, Gilles Gilles MOURY SDLS WG Co-Chair De : sls-sea-dls-bounces at mailman.ccsds.org [ mailto:sls-sea-dls-bounces at mailman.ccsds.org] De la part de Moury Gilles Envoyé : mercredi 19 août 2015 15:45 À : Daniel.Fischer at esa.int; Ignacio.Aguilar.Sanchez at esa.int Cc : sls-sea-dls at mailman.ccsds.org; sls-sea-dls-bounces at mailman.ccsds.org Objet : RE: [Sls-sea-dls] results of CESG poll for SDLS BB publication Dear Daniel, Ignacio and SDLS WG members, I concur with Ignacio and Daniel proposals for Peter’s comments disposition. More specifically, taking Peter’s comments one by one (I attach Peter’s commented version for reference): P 1-1 : OK for the 2 comments P 1-3, 3-1 : The usage of the term Payload: this term is duly defined upfront in SDLS book and therefore this definition replaces the CCSDS generic definition in the context of SDLS. The term is used consistently throughout the document. Besides the term payload is widely used with that meaning in the COMSEC domain. I agree with Ignacio and Daniel that we should discuss this with Peter and advocate for keeping this term. P 2-1 : Comment not understood. To be discussed with Peter. In any case we can remove the parenthesis in the note if that causes problem. P 2-2 : I do not support inserting in SDLS a duplicate of figures 6-1 of TM, TC and AOS books, but we could simply refer/point to it respectively in sections 2.2.3, 2.2.4 and 2.2.5 with a statement like: “the structure of the TM/TC/AOS Transfer Frame with SDLS is given in Figure 6-1 of [1]/[2]/[3]. This statement could also be placed once in section 2.3.1.4 Security Header and Trailer. P 2-5 : Figure 2-4 : we need to change A and B to AOS ApplySecurity payload or return (instead of TM ApplySecurity …) P2-8, 4-9, 4-12 : NOTE on sequence number rollover : I would suggest keeping the NOTE but limiting it to the first sentence (The interpretation of a sequence number rollover (to zero) is mission specific) and then pointing to a specific SDLS green book subsection where this is discussed in more details. This would avoid confusion for implementers making it clear there is no specific recommendation (should) or permission (may) for that subject in the Blue Book. P 3-7, 3-10 : SA management service: I would propose keeping subsection 3.4.2 intact (SA management service parameters). Replace the NOTE in 3.4.3 (SA management service directives) by : “The directives for SA management will be specified in a CCSDS recommendation currently under development (355.1-B: SDLS extended procedures).” To be coherent with that, I would replace the second sentence of subsection 3.4.1 by: “The service directives necessary to manage the SA parameters will be specified in a CCSDS recommendation currently under development (355.1-B: SDLS extended procedures)”. As suggested by Daniel, we could add a column in table 6-1 to indicate the correspondence between parameters denomination in subsection 3.4.2 and in Table 6-1. P 5-1: Peters comment: (no mention of payload in that section 5 “Use of the services with CCSDS protocols”). I would propose to show the “ApplySecurity payload” in figures 5-1 (TM transfer frame), 5-2 (TC), 5-3 (AOS). P 6-1 : OK to add unspecified (an unspecified management system). For the second comment (abstract SA data base) I tend to agree with Daniel, the SA data base is not abstract . It has to be implemented both on-ground and on-board. P B-1 : OK to replace “user-supplied data unit” by “transfer frame data field” to make it unambiguous. I hope we can converge with Peter on commonly agreed dispositions. We need to consolidate first our WG responses to his comments. Craig : let us know your position wrt the comments, so we can produce a redline version of the document with our proposed dispositions and associated explanations inserted. Best regards, Gilles Gilles MOURY CNES Toulouse De : Daniel.Fischer at esa.int [mailto:Daniel.Fischer at esa.int] Envoyé : jeudi 13 août 2015 14:51 À : Ignacio.Aguilar.Sanchez at esa.int Cc : Moury Gilles; sls-sea-dls at mailman.ccsds.org; sls-sea-dls-bounces at mailman.ccsds.org Objet : Re: [Sls-sea-dls] results of CESG poll for SDLS BB publication 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 , Cc: "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 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.[attachment "355x0b0_CESG_Approval with CESG comments dispositions 2.doc" 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. From Daniel.Fischer at esa.int Mon Aug 24 08:15:10 2015 From: Daniel.Fischer at esa.int (Daniel.Fischer at esa.int) Date: Mon, 24 Aug 2015 10:15:10 +0200 Subject: [Sls-sea-dls] RE: SDLS BB : proposal for PS comments dispositions In-Reply-To: References: <442F062EBF46F247A96B8A50EF3EB6F417049E7A@TW-MBX-P04.cnesnet.ad.cnes.fr> <321CDC5F015F3B418419F05A79B668BA18DC0A1B@NDJSMBX101.ndc.nasa.gov> Message-ID: <21856_1440404116_55DAD294_21856_15_1_OF73A3573F.8E15C6A1-ONC1257EAB.002C4E21-C1257EAB.002D54AE@esa.int> Dear all, The BB will be revised only after 5 years once it has been published. Thus, putting a statement like "Implementation of the services necessary to manage the parameters contained in the SA data base is a mission-specific function. Service directives for managing the SA parameters in-line will be specified in a CCSDS recommendation currently under development (355.1-B: SDLS Extended Procedures)." seems a bit odd. I would formulate it more "timeless". Maybe something like "Implementation of the services necessary to manage the parameters contained in the SA data base is a mission-specific function. Service directives for managing the SA parameters in-line are specified in the SDLS Extended Procedures CCSDS recommendation (reference 355.1-B: SDLS Extended Procedures). At the time of publication of this document, the Extended Procedures book is still under development ." Furthermore, I agree with Ignacios statement regarding Section 6.1. Unspecified ins better. It may also be worth to add a reference to Section 3.4.1. 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/estec/ESA To: "Biggerstaff, Craig (JSC-CD221)[LOCKHEED MARTIN CORP]" , Cc: "Daniel.Fischer at esa.int" , "Moury Gilles" , "howie.weiss at sparta.com" , "sls-sea-dls at mailman.ccsds.org" Date: 24/08/2015 10:00 Subject: Re: [Sls-sea-dls] RE: SDLS BB : proposal for PS comments dispositions Dear Craig et al, The proposed update as well as the responses to Peter's comments are almost fine with me. My only problem is adding the word 'unspecified' before 'management' in section 6.1. This language is not consistent with the language used with the TC, TM and AOS BBs. We have attempted to harmonise the four standards to the best of our ability. Either we state everywhere that the management is not specified or we do not. And we do it in the same way. To be clear, each of the four standards contains a statement in section 1.2 where the absence of specification for the management activities is stated. The word 'unspecified' does not show up a single time in TC, TM and AOS BBs. In order to avoid additional modifications on TC, TM and AOS BBs to achieve full consistency with this topic, I would propose to remove the word 'unspecified'. Kind regards, Ignacio From: "Biggerstaff, Craig (JSC-CD221)[LOCKHEED MARTIN CORP]" To: "Moury Gilles" , "Ignacio.Aguilar.Sanchez at esa.int" , "Daniel.Fischer at esa.int" , "howie.weiss at sparta.com" Cc: "sls-sea-dls at mailman.ccsds.org" Date: 21/08/2015 22:55 Subject: [Sls-sea-dls] RE: SDLS BB : proposal for PS comments dispositions Sent by: sls-sea-dls-bounces at mailman.ccsds.org Dear WG members, Gilles, thank you for adding in the proposed dispositions for Peter Shames. I have added the NOTE to section 1.1 to answer Tomaso de Cola?s and Keith Scott?s conditions, updated figures 2-4,5-1,5-2,5-3, and made one or two minor alterations to the proposed language to avoid an implicit dependency of 355.0 upon 355.1. If these changes meet with the WG?s satisfaction, I will forward them to Peter for his review and cc Tom Gannett per the conditional approval procedures. Best regards, Craig From: Moury Gilles [mailto:Gilles.Moury at cnes.fr] Sent: Friday, August 21, 2015 11:07 AM To: Biggerstaff, Craig (JSC-CD221)[LOCKHEED MARTIN CORP]; Ignacio.Aguilar.Sanchez at esa.int; Daniel.Fischer at esa.int; howie.weiss at sparta.com Cc: sls-sea-dls at mailman.ccsds.org; sls-sea-dls-bounces at mailman.ccsds.org Subject: SDLS BB : proposal for PS comments dispositions Dear SDLS WG members, Please find attached a redline version of the SDLS BB with proposed dispositions for Peter Shames comments (in line with my herebelow mail). The text modifications are tentatively justified wrt Peter?s comment. We should converge internally to the WG before sending the proposed redline to Peter Shames. Craig, as technical editor of the book, could you please take the lead on this ? I am leaving for one week so will not be able to make any progress. Best regards, Gilles Gilles MOURY SDLS WG Co-Chair De : sls-sea-dls-bounces at mailman.ccsds.org [ mailto:sls-sea-dls-bounces at mailman.ccsds.org] De la part de Moury Gilles Envoyé : mercredi 19 août 2015 15:45 À : Daniel.Fischer at esa.int; Ignacio.Aguilar.Sanchez at esa.int Cc : sls-sea-dls at mailman.ccsds.org; sls-sea-dls-bounces at mailman.ccsds.org Objet : RE: [Sls-sea-dls] results of CESG poll for SDLS BB publication Dear Daniel, Ignacio and SDLS WG members, I concur with Ignacio and Daniel proposals for Peter?s comments disposition. More specifically, taking Peter?s comments one by one (I attach Peter?s commented version for reference): P 1-1 : OK for the 2 comments P 1-3, 3-1 : The usage of the term Payload: this term is duly defined upfront in SDLS book and therefore this definition replaces the CCSDS generic definition in the context of SDLS. The term is used consistently throughout the document. Besides the term payload is widely used with that meaning in the COMSEC domain. I agree with Ignacio and Daniel that we should discuss this with Peter and advocate for keeping this term. P 2-1 : Comment not understood. To be discussed with Peter. In any case we can remove the parenthesis in the note if that causes problem. P 2-2 : I do not support inserting in SDLS a duplicate of figures 6-1 of TM, TC and AOS books, but we could simply refer/point to it respectively in sections 2.2.3, 2.2.4 and 2.2.5 with a statement like: ?the structure of the TM/TC/AOS Transfer Frame with SDLS is given in Figure 6-1 of [1]/[2]/[3]. This statement could also be placed once in section 2.3.1.4 Security Header and Trailer. P 2-5 : Figure 2-4 : we need to change A and B to AOS ApplySecurity payload or return (instead of TM ApplySecurity ?) P2-8, 4-9, 4-12 : NOTE on sequence number rollover : I would suggest keeping the NOTE but limiting it to the first sentence (The interpretation of a sequence number rollover (to zero) is mission specific) and then pointing to a specific SDLS green book subsection where this is discussed in more details. This would avoid confusion for implementers making it clear there is no specific recommendation (should) or permission (may) for that subject in the Blue Book. P 3-7, 3-10 : SA management service: I would propose keeping subsection 3.4.2 intact (SA management service parameters). Replace the NOTE in 3.4.3 (SA management service directives) by : ?The directives for SA management will be specified in a CCSDS recommendation currently under development (355.1-B: SDLS extended procedures).? To be coherent with that, I would replace the second sentence of subsection 3.4.1 by: ?The service directives necessary to manage the SA parameters will be specified in a CCSDS recommendation currently under development (355.1-B: SDLS extended procedures)?. As suggested by Daniel, we could add a column in table 6-1 to indicate the correspondence between parameters denomination in subsection 3.4.2 and in Table 6-1. P 5-1: Peters comment: (no mention of payload in that section 5 ?Use of the services with CCSDS protocols?). I would propose to show the ?ApplySecurity payload? in figures 5-1 (TM transfer frame), 5-2 (TC), 5-3 (AOS). P 6-1 : OK to add unspecified (an unspecified management system). For the second comment (abstract SA data base) I tend to agree with Daniel, the SA data base is not abstract . It has to be implemented both on-ground and on-board. P B-1 : OK to replace ?user-supplied data unit? by ?transfer frame data field? to make it unambiguous. I hope we can converge with Peter on commonly agreed dispositions. We need to consolidate first our WG responses to his comments. Craig : let us know your position wrt the comments, so we can produce a redline version of the document with our proposed dispositions and associated explanations inserted. Best regards, Gilles Gilles MOURY CNES Toulouse De : Daniel.Fischer at esa.int [mailto:Daniel.Fischer at esa.int] Envoyé : jeudi 13 août 2015 14:51 À : Ignacio.Aguilar.Sanchez at esa.int Cc : Moury Gilles; sls-sea-dls at mailman.ccsds.org; sls-sea-dls-bounces at mailman.ccsds.org Objet : Re: [Sls-sea-dls] results of CESG poll for SDLS BB publication 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 , Cc: "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 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.[attachment "355x0b0_CESG_Approval with CESG comments dispositions 2.doc" 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ignacio.Aguilar.Sanchez at esa.int Mon Aug 24 08:47:12 2015 From: Ignacio.Aguilar.Sanchez at esa.int (Ignacio.Aguilar.Sanchez at esa.int) Date: Mon, 24 Aug 2015 10:47:12 +0200 Subject: Fw: [Sls-sea-dls] RE: SDLS BB : proposal for PS comments dispositions Message-ID: <27959_1440406034_55DADA12_27959_5_1_OFCC5F9A6E.85A4C934-ONC1257EAB.002FE42E-C1257EAB.00304412@esa.int> Dear all, I agree with Daniel in formulating a less time-dependent sentence when referring to the Extended Procedures. His proposal is fine with me. Kind regards, Ignacio ----- Forwarded by Ignacio Aguilar Sanchez/estec/ESA on 24/08/2015 10:43 ----- From: Daniel Fischer/esoc/ESA To: Ignacio Aguilar Sanchez/estec/ESA at ESA Cc: "Biggerstaff, Craig (JSC-CD221)[LOCKHEED MARTIN CORP]" , "Moury Gilles" , "howie.weiss at sparta.com" , "sls-sea-dls at mailman.ccsds.org" Date: 24/08/2015 10:15 Subject: Re: [Sls-sea-dls] RE: SDLS BB : proposal for PS comments dispositions Dear all, The BB will be revised only after 5 years once it has been published. Thus, putting a statement like "Implementation of the services necessary to manage the parameters contained in the SA data base is a mission-specific function. Service directives for managing the SA parameters in-line will be specified in a CCSDS recommendation currently under development (355.1-B: SDLS Extended Procedures)." seems a bit odd. I would formulate it more "timeless". Maybe something like "Implementation of the services necessary to manage the parameters contained in the SA data base is a mission-specific function. Service directives for managing the SA parameters in-line are specified in the SDLS Extended Procedures CCSDS recommendation (reference 355.1-B: SDLS Extended Procedures). At the time of publication of this document, the Extended Procedures book is still under development ." Furthermore, I agree with Ignacios statement regarding Section 6.1. Unspecified ins better. It may also be worth to add a reference to Section 3.4.1. 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/estec/ESA To: "Biggerstaff, Craig (JSC-CD221)[LOCKHEED MARTIN CORP]" , Cc: "Daniel.Fischer at esa.int" , "Moury Gilles" , "howie.weiss at sparta.com" , "sls-sea-dls at mailman.ccsds.org" Date: 24/08/2015 10:00 Subject: Re: [Sls-sea-dls] RE: SDLS BB : proposal for PS comments dispositions Dear Craig et al, The proposed update as well as the responses to Peter's comments are almost fine with me. My only problem is adding the word 'unspecified' before 'management' in section 6.1. This language is not consistent with the language used with the TC, TM and AOS BBs. We have attempted to harmonise the four standards to the best of our ability. Either we state everywhere that the management is not specified or we do not. And we do it in the same way. To be clear, each of the four standards contains a statement in section 1.2 where the absence of specification for the management activities is stated. The word 'unspecified' does not show up a single time in TC, TM and AOS BBs. In order to avoid additional modifications on TC, TM and AOS BBs to achieve full consistency with this topic, I would propose to remove the word 'unspecified'. Kind regards, Ignacio From: "Biggerstaff, Craig (JSC-CD221)[LOCKHEED MARTIN CORP]" To: "Moury Gilles" , "Ignacio.Aguilar.Sanchez at esa.int" , "Daniel.Fischer at esa.int" , "howie.weiss at sparta.com" Cc: "sls-sea-dls at mailman.ccsds.org" Date: 21/08/2015 22:55 Subject: [Sls-sea-dls] RE: SDLS BB : proposal for PS comments dispositions Sent by: sls-sea-dls-bounces at mailman.ccsds.org Dear WG members, Gilles, thank you for adding in the proposed dispositions for Peter Shames. I have added the NOTE to section 1.1 to answer Tomaso de Cola’s and Keith Scott’s conditions, updated figures 2-4,5-1,5-2,5-3, and made one or two minor alterations to the proposed language to avoid an implicit dependency of 355.0 upon 355.1. If these changes meet with the WG’s satisfaction, I will forward them to Peter for his review and cc Tom Gannett per the conditional approval procedures. Best regards, Craig From: Moury Gilles [mailto:Gilles.Moury at cnes.fr] Sent: Friday, August 21, 2015 11:07 AM To: Biggerstaff, Craig (JSC-CD221)[LOCKHEED MARTIN CORP]; Ignacio.Aguilar.Sanchez at esa.int; Daniel.Fischer at esa.int; howie.weiss at sparta.com Cc: sls-sea-dls at mailman.ccsds.org; sls-sea-dls-bounces at mailman.ccsds.org Subject: SDLS BB : proposal for PS comments dispositions Dear SDLS WG members, Please find attached a redline version of the SDLS BB with proposed dispositions for Peter Shames comments (in line with my herebelow mail). The text modifications are tentatively justified wrt Peter’s comment. We should converge internally to the WG before sending the proposed redline to Peter Shames. Craig, as technical editor of the book, could you please take the lead on this ? I am leaving for one week so will not be able to make any progress. Best regards, Gilles Gilles MOURY SDLS WG Co-Chair De : sls-sea-dls-bounces at mailman.ccsds.org [ mailto:sls-sea-dls-bounces at mailman.ccsds.org] De la part de Moury Gilles Envoyé : mercredi 19 août 2015 15:45 À : Daniel.Fischer at esa.int; Ignacio.Aguilar.Sanchez at esa.int Cc : sls-sea-dls at mailman.ccsds.org; sls-sea-dls-bounces at mailman.ccsds.org Objet : RE: [Sls-sea-dls] results of CESG poll for SDLS BB publication Dear Daniel, Ignacio and SDLS WG members, I concur with Ignacio and Daniel proposals for Peter’s comments disposition. More specifically, taking Peter’s comments one by one (I attach Peter’s commented version for reference): P 1-1 : OK for the 2 comments P 1-3, 3-1 : The usage of the term Payload: this term is duly defined upfront in SDLS book and therefore this definition replaces the CCSDS generic definition in the context of SDLS. The term is used consistently throughout the document. Besides the term payload is widely used with that meaning in the COMSEC domain. I agree with Ignacio and Daniel that we should discuss this with Peter and advocate for keeping this term. P 2-1 : Comment not understood. To be discussed with Peter. In any case we can remove the parenthesis in the note if that causes problem. P 2-2 : I do not support inserting in SDLS a duplicate of figures 6-1 of TM, TC and AOS books, but we could simply refer/point to it respectively in sections 2.2.3, 2.2.4 and 2.2.5 with a statement like: “the structure of the TM/TC/AOS Transfer Frame with SDLS is given in Figure 6-1 of [1]/[2]/[3]. This statement could also be placed once in section 2.3.1.4 Security Header and Trailer. P 2-5 : Figure 2-4 : we need to change A and B to AOS ApplySecurity payload or return (instead of TM ApplySecurity …) P2-8, 4-9, 4-12 : NOTE on sequence number rollover : I would suggest keeping the NOTE but limiting it to the first sentence (The interpretation of a sequence number rollover (to zero) is mission specific) and then pointing to a specific SDLS green book subsection where this is discussed in more details. This would avoid confusion for implementers making it clear there is no specific recommendation (should) or permission (may) for that subject in the Blue Book. P 3-7, 3-10 : SA management service: I would propose keeping subsection 3.4.2 intact (SA management service parameters). Replace the NOTE in 3.4.3 (SA management service directives) by : “The directives for SA management will be specified in a CCSDS recommendation currently under development (355.1-B: SDLS extended procedures).” To be coherent with that, I would replace the second sentence of subsection 3.4.1 by: “The service directives necessary to manage the SA parameters will be specified in a CCSDS recommendation currently under development (355.1-B: SDLS extended procedures)”. As suggested by Daniel, we could add a column in table 6-1 to indicate the correspondence between parameters denomination in subsection 3.4.2 and in Table 6-1. P 5-1: Peters comment: (no mention of payload in that section 5 “Use of the services with CCSDS protocols”). I would propose to show the “ApplySecurity payload” in figures 5-1 (TM transfer frame), 5-2 (TC), 5-3 (AOS). P 6-1 : OK to add unspecified (an unspecified management system). For the second comment (abstract SA data base) I tend to agree with Daniel, the SA data base is not abstract . It has to be implemented both on-ground and on-board. P B-1 : OK to replace “user-supplied data unit” by “transfer frame data field” to make it unambiguous. I hope we can converge with Peter on commonly agreed dispositions. We need to consolidate first our WG responses to his comments. Craig : let us know your position wrt the comments, so we can produce a redline version of the document with our proposed dispositions and associated explanations inserted. Best regards, Gilles Gilles MOURY CNES Toulouse De : Daniel.Fischer at esa.int [mailto:Daniel.Fischer at esa.int] Envoyé : jeudi 13 août 2015 14:51 À : Ignacio.Aguilar.Sanchez at esa.int Cc : Moury Gilles; sls-sea-dls at mailman.ccsds.org; sls-sea-dls-bounces at mailman.ccsds.org Objet : Re: [Sls-sea-dls] results of CESG poll for SDLS BB publication 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 , Cc: "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 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.[attachment "355x0b0_CESG_Approval with CESG comments dispositions 2.doc" 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. From Daniel.Fischer at esa.int Thu Aug 27 07:54:35 2015 From: Daniel.Fischer at esa.int (Daniel.Fischer at esa.int) Date: Thu, 27 Aug 2015 09:54:35 +0200 Subject: [Sls-sea-dls] [SDLS Extended Procedures] TLV Format Question Message-ID: <8204_1440662079_55DEC23F_8204_17_1_OF24A9CC73.CB63AD4E-ONC1257EAE.002AEC82-C1257EAE.002B736B@esa.int> 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From craig.biggerstaff at nasa.gov Thu Aug 27 15:17:15 2015 From: craig.biggerstaff at nasa.gov (Biggerstaff, Craig (JSC-CD221)[LOCKHEED MARTIN CORP]) Date: Thu, 27 Aug 2015 15:17:15 +0000 Subject: [Sls-sea-dls] RE: SDLS BB : proposal for PS comments dispositions In-Reply-To: <21856_1440404116_55DAD294_21856_15_1_OF73A3573F.8E15C6A1-ONC1257EAB.002C4E21-C1257EAB.002D54AE@esa.int> References: <442F062EBF46F247A96B8A50EF3EB6F417049E7A@TW-MBX-P04.cnesnet.ad.cnes.fr> <321CDC5F015F3B418419F05A79B668BA18DC0A1B@NDJSMBX101.ndc.nasa.gov> , <21856_1440404116_55DAD294_21856_15_1_OF73A3573F.8E15C6A1-ONC1257EAB.002C4E21-C1257EAB.002D54AE@esa.int> Message-ID: <321CDC5F015F3B418419F05A79B668BA18ED81CE@NDJSMBX101.ndc.nasa.gov> Dear all, Attached is the latest iteration of the BB text changes to satisfy CESG conditions. Please look at it quickly, as I want to send it to Peter et al. later today. Thanks, Craig ________________________________________ From: Daniel.Fischer at esa.int [Daniel.Fischer at esa.int] Sent: Monday, August 24, 2015 03:15 To: Ignacio.Aguilar.Sanchez at esa.int Cc: Biggerstaff, Craig (JSC-CD221)[LOCKHEED MARTIN CORP]; Moury Gilles; howie.weiss at sparta.com; sls-sea-dls at mailman.ccsds.org Subject: Re: [Sls-sea-dls] RE: SDLS BB : proposal for PS comments dispositions Dear all, The BB will be revised only after 5 years once it has been published. Thus, putting a statement like "Implementation of the services necessary to manage the parameters contained in the SA data base is a mission-specific function. Service directives for managing the SA parameters in-line will be specified in a CCSDS recommendation currently under development (355.1-B: SDLS Extended Procedures)." seems a bit odd. I would formulate it more "timeless". Maybe something like "Implementation of the services necessary to manage the parameters contained in the SA data base is a mission-specific function. Service directives for managing the SA parameters in-line are specified in the SDLS Extended Procedures CCSDS recommendation (reference 355.1-B: SDLS Extended Procedures). At the time of publication of this document, the Extended Procedures book is still under development ." Furthermore, I agree with Ignacios statement regarding Section 6.1. Unspecified ins better. It may also be worth to add a reference to Section 3.4.1. 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/estec/ESA To: "Biggerstaff, Craig (JSC-CD221)[LOCKHEED MARTIN CORP]" , Cc: "Daniel.Fischer at esa.int" , "Moury Gilles" , "howie.weiss at sparta.com" , "sls-sea-dls at mailman.ccsds.org" Date: 24/08/2015 10:00 Subject: Re: [Sls-sea-dls] RE: SDLS BB : proposal for PS comments dispositions ________________________________ Dear Craig et al, The proposed update as well as the responses to Peter's comments are almost fine with me. My only problem is adding the word 'unspecified' before 'management' in section 6.1. This language is not consistent with the language used with the TC, TM and AOS BBs. We have attempted to harmonise the four standards to the best of our ability. Either we state everywhere that the management is not specified or we do not. And we do it in the same way. To be clear, each of the four standards contains a statement in section 1.2 where the absence of specification for the management activities is stated. The word 'unspecified' does not show up a single time in TC, TM and AOS BBs. In order to avoid additional modifications on TC, TM and AOS BBs to achieve full consistency with this topic, I would propose to remove the word 'unspecified'. Kind regards, Ignacio From: "Biggerstaff, Craig (JSC-CD221)[LOCKHEED MARTIN CORP]" To: "Moury Gilles" , "Ignacio.Aguilar.Sanchez at esa.int" , "Daniel.Fischer at esa.int" , "howie.weiss at sparta.com" Cc: "sls-sea-dls at mailman.ccsds.org" Date: 21/08/2015 22:55 Subject: [Sls-sea-dls] RE: SDLS BB : proposal for PS comments dispositions Sent by: sls-sea-dls-bounces at mailman.ccsds.org ________________________________ Dear WG members, Gilles, thank you for adding in the proposed dispositions for Peter Shames. I have added the NOTE to section 1.1 to answer Tomaso de Cola’s and Keith Scott’s conditions, updated figures 2-4,5-1,5-2,5-3, and made one or two minor alterations to the proposed language to avoid an implicit dependency of 355.0 upon 355.1. If these changes meet with the WG’s satisfaction, I will forward them to Peter for his review and cc Tom Gannett per the conditional approval procedures. Best regards, Craig From: Moury Gilles [mailto:Gilles.Moury at cnes.fr] Sent: Friday, August 21, 2015 11:07 AM To: Biggerstaff, Craig (JSC-CD221)[LOCKHEED MARTIN CORP]; Ignacio.Aguilar.Sanchez at esa.int; Daniel.Fischer at esa.int; howie.weiss at sparta.com Cc: sls-sea-dls at mailman.ccsds.org; sls-sea-dls-bounces at mailman.ccsds.org Subject: SDLS BB : proposal for PS comments dispositions Dear SDLS WG members, Please find attached a redline version of the SDLS BB with proposed dispositions for Peter Shames comments (in line with my herebelow mail). The text modifications are tentatively justified wrt Peter’s comment. We should converge internally to the WG before sending the proposed redline to Peter Shames. Craig, as technical editor of the book, could you please take the lead on this ? I am leaving for one week so will not be able to make any progress. Best regards, Gilles Gilles MOURY SDLS WG Co-Chair De : sls-sea-dls-bounces at mailman.ccsds.org [mailto:sls-sea-dls-bounces at mailman.ccsds.org] De la part de Moury Gilles Envoyé : mercredi 19 août 2015 15:45 À : Daniel.Fischer at esa.int; Ignacio.Aguilar.Sanchez at esa.int Cc : sls-sea-dls at mailman.ccsds.org; sls-sea-dls-bounces at mailman.ccsds.org Objet : RE: [Sls-sea-dls] results of CESG poll for SDLS BB publication Dear Daniel, Ignacio and SDLS WG members, I concur with Ignacio and Daniel proposals for Peter’s comments disposition. More specifically, taking Peter’s comments one by one (I attach Peter’s commented version for reference): P 1-1 : OK for the 2 comments P 1-3, 3-1 : The usage of the term Payload: this term is duly defined upfront in SDLS book and therefore this definition replaces the CCSDS generic definition in the context of SDLS. The term is used consistently throughout the document. Besides the term payload is widely used with that meaning in the COMSEC domain. I agree with Ignacio and Daniel that we should discuss this with Peter and advocate for keeping this term. P 2-1 : Comment not understood. To be discussed with Peter. In any case we can remove the parenthesis in the note if that causes problem. P 2-2 : I do not support inserting in SDLS a duplicate of figures 6-1 of TM, TC and AOS books, but we could simply refer/point to it respectively in sections 2.2.3, 2.2.4 and 2.2.5 with a statement like: “the structure of the TM/TC/AOS Transfer Frame with SDLS is given in Figure 6-1 of [1]/[2]/[3]. This statement could also be placed once in section 2.3.1.4 Security Header and Trailer. P 2-5 : Figure 2-4 : we need to change A and B to AOS ApplySecurity payload or return (instead of TM ApplySecurity …) P2-8, 4-9, 4-12 : NOTE on sequence number rollover : I would suggest keeping the NOTE but limiting it to the first sentence (The interpretation of a sequence number rollover (to zero) is mission specific) and then pointing to a specific SDLS green book subsection where this is discussed in more details. This would avoid confusion for implementers making it clear there is no specific recommendation (should) or permission (may) for that subject in the Blue Book. P 3-7, 3-10 : SA management service: I would propose keeping subsection 3.4.2 intact (SA management service parameters). Replace the NOTE in 3.4.3 (SA management service directives) by : “The directives for SA management will be specified in a CCSDS recommendation currently under development (355.1-B: SDLS extended procedures).” To be coherent with that, I would replace the second sentence of subsection 3.4.1 by: “The service directives necessary to manage the SA parameters will be specified in a CCSDS recommendation currently under development (355.1-B: SDLS extended procedures)”. As suggested by Daniel, we could add a column in table 6-1 to indicate the correspondence between parameters denomination in subsection 3.4.2 and in Table 6-1. P 5-1: Peters comment: (no mention of payload in that section 5 “Use of the services with CCSDS protocols”). I would propose to show the “ApplySecurity payload” in figures 5-1 (TM transfer frame), 5-2 (TC), 5-3 (AOS). P 6-1 : OK to add unspecified (an unspecified management system). For the second comment (abstract SA data base) I tend to agree with Daniel, the SA data base is not abstract . It has to be implemented both on-ground and on-board. P B-1 : OK to replace “user-supplied data unit” by “transfer frame data field” to make it unambiguous. I hope we can converge with Peter on commonly agreed dispositions. We need to consolidate first our WG responses to his comments. Craig : let us know your position wrt the comments, so we can produce a redline version of the document with our proposed dispositions and associated explanations inserted. Best regards, Gilles Gilles MOURY CNES Toulouse De : Daniel.Fischer at esa.int [mailto:Daniel.Fischer at esa.int] Envoyé : jeudi 13 août 2015 14:51 À : Ignacio.Aguilar.Sanchez at esa.int Cc : Moury Gilles; sls-sea-dls at mailman.ccsds.org; sls-sea-dls-bounces at mailman.ccsds.org Objet : Re: [Sls-sea-dls] results of CESG poll for SDLS BB publication 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 >, Cc: "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 > To: "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.[attachment "355x0b0_CESG_Approval with CESG comments dispositions 2.doc" 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. -------------- next part -------------- A non-text attachment was scrubbed... Name: 355x0b0_CESG_Approval with CESG comments dispositions 3.doc Type: application/msword Size: 849920 bytes Desc: 355x0b0_CESG_Approval with CESG comments dispositions 3.doc URL: From Ignacio.Aguilar.Sanchez at esa.int Fri Aug 28 05:05:03 2015 From: Ignacio.Aguilar.Sanchez at esa.int (Ignacio.Aguilar.Sanchez at esa.int) Date: Fri, 28 Aug 2015 07:05:03 +0200 Subject: [Sls-sea-dls] RE: SDLS BB : proposal for PS comments dispositions In-Reply-To: <321CDC5F015F3B418419F05A79B668BA18ED81CE@NDJSMBX101.ndc.nasa.gov> References: <442F062EBF46F247A96B8A50EF3EB6F417049E7A@TW-MBX-P04.cnesnet.ad.cnes.fr> <321CDC5F015F3B418419F05A79B668BA18DC0A1B@NDJSMBX101.ndc.nasa.gov> , <21856_1440404116_55DAD294_21856_15_1_OF73A3573F.8E15C6A1-ONC1257EAB.002C4E21-C1257EAB.002D54AE@esa.int> <321CDC5F015F3B418419F05A79B668BA18ED81CE@NDJSMBX101.ndc.nasa.gov> Message-ID: <19387_1440738312_55DFEC08_19387_140_1_OF2E4B3950.AD695DF0-ONC1257EAF.001B5F71-C1257EAF.001BECA6@esa.int> Craig, Could not read this e-mail earlier. Yesterday on mission in Germany and meeting without connectivity. The update is fine with me. Kind regards, Ignacio From: "Biggerstaff, Craig (JSC-CD221)[LOCKHEED MARTIN CORP]" To: "Daniel.Fischer at esa.int" , "Ignacio.Aguilar.Sanchez at esa.int" Cc: "sls-sea-dls at mailman.ccsds.org" , "howie.weiss at sparta.com" , "Moury Gilles" Date: 27/08/2015 17:18 Subject: RE: [Sls-sea-dls] RE: SDLS BB : proposal for PS comments dispositions Sent by: sls-sea-dls-bounces at mailman.ccsds.org Dear all, Attached is the latest iteration of the BB text changes to satisfy CESG conditions. Please look at it quickly, as I want to send it to Peter et al. later today. Thanks, Craig ________________________________________ From: Daniel.Fischer at esa.int [Daniel.Fischer at esa.int] Sent: Monday, August 24, 2015 03:15 To: Ignacio.Aguilar.Sanchez at esa.int Cc: Biggerstaff, Craig (JSC-CD221)[LOCKHEED MARTIN CORP]; Moury Gilles; howie.weiss at sparta.com; sls-sea-dls at mailman.ccsds.org Subject: Re: [Sls-sea-dls] RE: SDLS BB : proposal for PS comments dispositions Dear all, The BB will be revised only after 5 years once it has been published. Thus, putting a statement like "Implementation of the services necessary to manage the parameters contained in the SA data base is a mission-specific function. Service directives for managing the SA parameters in-line will be specified in a CCSDS recommendation currently under development (355.1-B: SDLS Extended Procedures)." seems a bit odd. I would formulate it more "timeless". Maybe something like "Implementation of the services necessary to manage the parameters contained in the SA data base is a mission-specific function. Service directives for managing the SA parameters in-line are specified in the SDLS Extended Procedures CCSDS recommendation (reference 355.1-B: SDLS Extended Procedures). At the time of publication of this document, the Extended Procedures book is still under development ." Furthermore, I agree with Ignacios statement regarding Section 6.1. Unspecified ins better. It may also be worth to add a reference to Section 3.4.1. 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/estec/ESA To: "Biggerstaff, Craig (JSC-CD221)[LOCKHEED MARTIN CORP]" , Cc: "Daniel.Fischer at esa.int" , "Moury Gilles" , "howie.weiss at sparta.com" , "sls-sea-dls at mailman.ccsds.org" Date: 24/08/2015 10:00 Subject: Re: [Sls-sea-dls] RE: SDLS BB : proposal for PS comments dispositions ________________________________ Dear Craig et al, The proposed update as well as the responses to Peter's comments are almost fine with me. My only problem is adding the word 'unspecified' before 'management' in section 6.1. This language is not consistent with the language used with the TC, TM and AOS BBs. We have attempted to harmonise the four standards to the best of our ability. Either we state everywhere that the management is not specified or we do not. And we do it in the same way. To be clear, each of the four standards contains a statement in section 1.2 where the absence of specification for the management activities is stated. The word 'unspecified' does not show up a single time in TC, TM and AOS BBs. In order to avoid additional modifications on TC, TM and AOS BBs to achieve full consistency with this topic, I would propose to remove the word 'unspecified'. Kind regards, Ignacio From: "Biggerstaff, Craig (JSC-CD221)[LOCKHEED MARTIN CORP]" To: "Moury Gilles" , "Ignacio.Aguilar.Sanchez at esa.int" , "Daniel.Fischer at esa.int" , "howie.weiss at sparta.com" Cc: "sls-sea-dls at mailman.ccsds.org" Date: 21/08/2015 22:55 Subject: [Sls-sea-dls] RE: SDLS BB : proposal for PS comments dispositions Sent by: sls-sea-dls-bounces at mailman.ccsds.org ________________________________ Dear WG members, Gilles, thank you for adding in the proposed dispositions for Peter Shames. I have added the NOTE to section 1.1 to answer Tomaso de Cola’s and Keith Scott’s conditions, updated figures 2-4,5-1,5-2,5-3, and made one or two minor alterations to the proposed language to avoid an implicit dependency of 355.0 upon 355.1. If these changes meet with the WG’s satisfaction, I will forward them to Peter for his review and cc Tom Gannett per the conditional approval procedures. Best regards, Craig From: Moury Gilles [mailto:Gilles.Moury at cnes.fr] Sent: Friday, August 21, 2015 11:07 AM To: Biggerstaff, Craig (JSC-CD221)[LOCKHEED MARTIN CORP]; Ignacio.Aguilar.Sanchez at esa.int; Daniel.Fischer at esa.int; howie.weiss at sparta.com Cc: sls-sea-dls at mailman.ccsds.org; sls-sea-dls-bounces at mailman.ccsds.org Subject: SDLS BB : proposal for PS comments dispositions Dear SDLS WG members, Please find attached a redline version of the SDLS BB with proposed dispositions for Peter Shames comments (in line with my herebelow mail). The text modifications are tentatively justified wrt Peter’s comment. We should converge internally to the WG before sending the proposed redline to Peter Shames. Craig, as technical editor of the book, could you please take the lead on this ? I am leaving for one week so will not be able to make any progress. Best regards, Gilles Gilles MOURY SDLS WG Co-Chair De : sls-sea-dls-bounces at mailman.ccsds.org< mailto:sls-sea-dls-bounces at mailman.ccsds.org> [ mailto:sls-sea-dls-bounces at mailman.ccsds.org] De la part de Moury Gilles Envoyé : mercredi 19 août 2015 15:45 À : Daniel.Fischer at esa.int; Ignacio.Aguilar.Sanchez at esa.int Cc : sls-sea-dls at mailman.ccsds.org; sls-sea-dls-bounces at mailman.ccsds.org< mailto:sls-sea-dls-bounces at mailman.ccsds.org> Objet : RE: [Sls-sea-dls] results of CESG poll for SDLS BB publication Dear Daniel, Ignacio and SDLS WG members, I concur with Ignacio and Daniel proposals for Peter’s comments disposition. More specifically, taking Peter’s comments one by one (I attach Peter’s commented version for reference): P 1-1 : OK for the 2 comments P 1-3, 3-1 : The usage of the term Payload: this term is duly defined upfront in SDLS book and therefore this definition replaces the CCSDS generic definition in the context of SDLS. The term is used consistently throughout the document. Besides the term payload is widely used with that meaning in the COMSEC domain. I agree with Ignacio and Daniel that we should discuss this with Peter and advocate for keeping this term. P 2-1 : Comment not understood. To be discussed with Peter. In any case we can remove the parenthesis in the note if that causes problem. P 2-2 : I do not support inserting in SDLS a duplicate of figures 6-1 of TM, TC and AOS books, but we could simply refer/point to it respectively in sections 2.2.3, 2.2.4 and 2.2.5 with a statement like: “the structure of the TM/TC/AOS Transfer Frame with SDLS is given in Figure 6-1 of [1]/[2]/[3]. This statement could also be placed once in section 2.3.1.4 Security Header and Trailer. P 2-5 : Figure 2-4 : we need to change A and B to AOS ApplySecurity payload or return (instead of TM ApplySecurity …) P2-8, 4-9, 4-12 : NOTE on sequence number rollover : I would suggest keeping the NOTE but limiting it to the first sentence (The interpretation of a sequence number rollover (to zero) is mission specific) and then pointing to a specific SDLS green book subsection where this is discussed in more details. This would avoid confusion for implementers making it clear there is no specific recommendation (should) or permission (may) for that subject in the Blue Book. P 3-7, 3-10 : SA management service: I would propose keeping subsection 3.4.2 intact (SA management service parameters). Replace the NOTE in 3.4.3 (SA management service directives) by : “The directives for SA management will be specified in a CCSDS recommendation currently under development (355.1-B: SDLS extended procedures).” To be coherent with that, I would replace the second sentence of subsection 3.4.1 by: “The service directives necessary to manage the SA parameters will be specified in a CCSDS recommendation currently under development (355.1-B: SDLS extended procedures)”. As suggested by Daniel, we could add a column in table 6-1 to indicate the correspondence between parameters denomination in subsection 3.4.2 and in Table 6-1. P 5-1: Peters comment: (no mention of payload in that section 5 “Use of the services with CCSDS protocols”). I would propose to show the “ApplySecurity payload” in figures 5-1 (TM transfer frame), 5-2 (TC), 5-3 (AOS). P 6-1 : OK to add unspecified (an unspecified management system). For the second comment (abstract SA data base) I tend to agree with Daniel, the SA data base is not abstract . It has to be implemented both on-ground and on-board. P B-1 : OK to replace “user-supplied data unit” by “transfer frame data field” to make it unambiguous. I hope we can converge with Peter on commonly agreed dispositions. We need to consolidate first our WG responses to his comments. Craig : let us know your position wrt the comments, so we can produce a redline version of the document with our proposed dispositions and associated explanations inserted. Best regards, Gilles Gilles MOURY CNES Toulouse De : Daniel.Fischer at esa.int [ mailto:Daniel.Fischer at esa.int] Envoyé : jeudi 13 août 2015 14:51 À : Ignacio.Aguilar.Sanchez at esa.int Cc : Moury Gilles; sls-sea-dls at mailman.ccsds.org< mailto:sls-sea-dls at mailman.ccsds.org>; sls-sea-dls-bounces at mailman.ccsds.org< mailto:sls-sea-dls-bounces at mailman.ccsds.org> Objet : Re: [Sls-sea-dls] results of CESG poll for SDLS BB publication 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< https://en.wikipedia.org/wiki/Computing> (sometimes referred to as the actual or body data) is the cargo of a data transmission< https://en.wikipedia.org/wiki/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< mailto:Ignacio.Aguilar.Sanchez at esa.int> To: Moury Gilles >, Cc: "sls-sea-dls at mailman.ccsds.org< mailto: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< mailto: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 > To: "sls-sea-dls at mailman.ccsds.org< mailto: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< mailto: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.[attachment "355x0b0_CESG_Approval with CESG comments dispositions 2.doc" 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. [attachment "355x0b0_CESG_Approval with CESG comments dispositions 3.doc" 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.