From greg.j.kazz at jpl.nasa.gov Fri Jan 4 00:08:45 2013 From: greg.j.kazz at jpl.nasa.gov (Kazz, Greg J (313B)) Date: Fri, 4 Jan 2013 00:08:45 +0000 Subject: [Sls-slp] SDLS impact on 232.0-B TC Space Data Link Protocol Message-ID: <3073AFAD38D0B846893757C13ABA7275234C99B6@ap-embx-sp20.RES.AD.JPL> Dear SLP WG, Happy New Year 2013 – I hope all is well with you and your families. Attached and soon to be place onto the CWE is the ESA/NASA joint proposal to incorporate the SDLS changes into the TC Space Data Link Protocol. Please review this document and send me any comments you may have regarding it. My goal is to have all comments collected within 3 weeks time, by Jan. 24, 2013. Best regards, Greg Kazz Chairman SLS-SLP WG -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 232x0b2pinkMAdeLLDec08+gpc.doc Type: application/msword Size: 1232896 bytes Desc: 232x0b2pinkMAdeLLDec08+gpc.doc URL: From greg.j.kazz at jpl.nasa.gov Fri Jan 4 00:48:43 2013 From: greg.j.kazz at jpl.nasa.gov (Kazz, Greg J (313B)) Date: Fri, 4 Jan 2013 00:48:43 +0000 Subject: [Sls-slp] SDLS proposed changes to AOS Space Data Link Protocol Message-ID: <3073AFAD38D0B846893757C13ABA7275234C99F9@ap-embx-sp20.RES.AD.JPL> Dear SLP WG, Now you will see the proposed update to the AOS Space Data Link Protocol (similar to TM and TC). Again I am asking you for your comments by Jan. 24, 2012. A important point to consider is the proposed optional parameter in this proposal for handling of frames failing verification of the authentication signature. Best regards, Greg Kazz Chairman SLS-SLP WG -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 732x0p21MAdeLLDec08+gpc.doc Type: application/msword Size: 880640 bytes Desc: 732x0p21MAdeLLDec08+gpc.doc URL: From greg.j.kazz at jpl.nasa.gov Tue Jan 15 21:38:00 2013 From: greg.j.kazz at jpl.nasa.gov (Kazz, Greg J (313B)) Date: Tue, 15 Jan 2013 21:38:00 +0000 Subject: [Sls-slp] Final SLP Meeting Minutes Fall 2012 CCSDS Meeting in Cleveland Message-ID: <3073AFAD38D0B846893757C13ABA7275234DA9CB@ap-embx-sp40.RES.AD.JPL> Dear SLP WG, Attached and also in the CWE under the 2012-Cleveland tab, please find the final Space Link Protocols meeting minutes. Best regards, Greg Kazz Chairman SLS-SLP WG -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SLS-SLP_Fall_2012_Minutes_Cleveland_Final.docx Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document Size: 708198 bytes Desc: SLS-SLP_Fall_2012_Minutes_Cleveland_Final.docx URL: From greg.j.kazz at jpl.nasa.gov Tue Jan 15 23:36:54 2013 From: greg.j.kazz at jpl.nasa.gov (Kazz, Greg J (313B)) Date: Tue, 15 Jan 2013 23:36:54 +0000 Subject: [Sls-slp] My comments on SDLS requirements on TM, TC, AOS Message-ID: <3073AFAD38D0B846893757C13ABA7275234DAA4A@ap-embx-sp40.RES.AD.JPL> G.P. and Marjorie, Attached please find my green lines (Word editing feature) to the documents you supplied us in Dec. 2012. As you will see most of my edits are editorial in nature, except for the issue regarding what should the link layer protocol do with the contents of the frame when the SDLS authentication function returns a authentication verification failure. In this case, I do not think there should be an option as I stated in my notes, the link layer protocol should not pass the data on to the user, but rather dispose of it and let the user know that allow the user to know optionally that it was an error detected by security fct. But we can discuss this further before and during the Spring meeting. Best regards, Greg -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 232x0b2pinkMAdeLLDec08+gpc+gjk.doc Type: application/msword Size: 1236480 bytes Desc: 232x0b2pinkMAdeLLDec08+gpc+gjk.doc URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 732x0p21MAdeLLDec08+gpc+gjk.doc Type: application/msword Size: 883712 bytes Desc: 732x0p21MAdeLLDec08+gpc+gjk.doc URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 132x0p11MAdeLLDec08+gpc.doc Type: application/msword Size: 929792 bytes Desc: 132x0p11MAdeLLDec08+gpc.doc URL: From Gian.Paolo.Calzolari at esa.int Wed Jan 16 10:19:06 2013 From: Gian.Paolo.Calzolari at esa.int (Gian.Paolo.Calzolari at esa.int) Date: Wed, 16 Jan 2013 11:19:06 +0100 Subject: [Sls-slp] My comments on SDLS requirements on TM, TC, AOS / Presence of a parameter In-Reply-To: <3073AFAD38D0B846893757C13ABA7275234DAA4A@ap-embx-sp40.RES.AD.JPL> References: <3073AFAD38D0B846893757C13ABA7275234DAA4A@ap-embx-sp40.RES.AD.JPL> Message-ID: <11983_1358331544_50F67E98_11983_10684_1_OFDC8B6CAD.CD58E399-ONC1257AF5.0034AFA1-C1257AF5.0038AEF2@esa.int> Dear Greg, thank you for your comments that will be discussed in the next days. I would like just to report about the usage of the zero value to indicate absence of a given parameter. You suggest to delete the two managed "Presence of Space Data Link Security Header" and "Presence of Space Data Link Security Trailer" as the length parameter covers the presence/absence of the field. We discussed extensively the matter and even acknowledging that a zero value for the length can be used by an implementation to show absence, we finally agreed not to use this option for the following reasons: - As stated in the chapter introduction, the managed parameters are defined in an abstract sense and are not intended to imply any particular implementation of a management system. As a consequence presenting two parameters instead of one is much more logical and explanatory to show that the given parameter can be omitted. Of course this is not preventing implementing the couple of parameters with a single "variable" in a real system. - most of the times, using a zero value for the length imposes to describe a non continuous range for the allowed values (e.g. 0 and 2 to 4 octets). Conversely the use of two parameters really shows only the allowed values. As well stating only "Integer" for allowed values would be incorrect. If needed, we can add a note to state that implementers may combine the two parameters in a single variable, but I do suggest keeping the two parameters for clarity and readability. Best regards Gian Paolo From: "Kazz, Greg J (313B)" To: "Gian.Paolo.Calzolari at esa.int" , "Marjorie de Lande Long" Cc: "sls-slp at mailman.ccsds.org" , Moury Gilles Date: 16/01/2013 00:39 Subject: [Sls-slp] My comments on SDLS requirements on TM, TC, AOS Sent by: sls-slp-bounces at mailman.ccsds.org G.P. and Marjorie, Attached please find my green lines (Word editing feature) to the documents you supplied us in Dec. 2012. As you will see most of my edits are editorial in nature, except for the issue regarding what should the link layer protocol do with the contents of the frame when the SDLS authentication function returns a authentication verification failure. In this case, I do not think there should be an option as I stated in my notes, the link layer protocol should not pass the data on to the user, but rather dispose of it and let the user know that allow the user to know optionally that it was an error detected by security fct. But we can discuss this further before and during the Spring meeting. Best regards, Greg [attachment "232x0b2pinkMAdeLLDec08+gpc+gjk.doc" deleted by Gian Paolo Calzolari/esoc/ESA] [attachment "732x0p21MAdeLLDec08+gpc+gjk.doc" deleted by Gian Paolo Calzolari/esoc/ESA] [attachment "132x0p11MAdeLLDec08+gpc.doc" deleted by Gian Paolo Calzolari/esoc/ESA] _______________________________________________ Sls-slp mailing list Sls-slp at mailman.ccsds.org http://mailman.ccsds.org/mailman/listinfo/sls-slp 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 greg.j.kazz at jpl.nasa.gov Fri Jan 18 01:35:30 2013 From: greg.j.kazz at jpl.nasa.gov (Kazz, Greg J (313B)) Date: Fri, 18 Jan 2013 01:35:30 +0000 Subject: [Sls-slp] Updated Version of Proximity-1 GB on SLP CWE now for review Message-ID: <3073AFAD38D0B846893757C13ABA7275234DAFE7@ap-embx-sp40.RES.AD.JPL> Dear SLP, Please find an updated version of the Proximity-1 GB: http://tinyurl.com/aufpuar One of our SLP work projects is to update this book, since the 3 prox-1 Blue Books have now been reviewed and almost completely finalized as a result of the 5-year review. I have edited the GB to reflect the commonalities we now have in all three books and also included pointers to CCSDS documents such as the TM Sync and Channel Coding GB that give guidance on the Convolutional and LDPC codes. You can see my red lines on the draft V2 document at the URL above. Matt Cosby – perhaps you can add a new Chapter 6 – Lessons Learned based upon your testing experience that you shared with us in Cleveland to this document. Enrico and Massimo – I also made small updates to the GB with respect to the Prox-1 Physical Layer and C&S sublayer based upon the changes we did to the respective Prox-1 Blue books. All – Please review my comments and provide me with your inputs by March 1, 2013. Best regards, Greg Kazz Chairman SLP WG -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg.j.kazz at jpl.nasa.gov Fri Jan 18 20:45:24 2013 From: greg.j.kazz at jpl.nasa.gov (Kazz, Greg J (313B)) Date: Fri, 18 Jan 2013 20:45:24 +0000 Subject: [Sls-slp] FW: Selecting a date for "SDLS-COP interaction" telecon In-Reply-To: <442F062EBF46F247A96B8A50EF3EB6F40AA53A@TW-MBX-P04.cnesnet.ad.cnes.fr> Message-ID: <3073AFAD38D0B846893757C13ABA7275234DC14E@ap-embx-sp40.RES.AD.JPL> Dear SLP, Please see the time for the SDLS-COP interaction telecon below. I hope you will participate. I will forward the details of how to join the telecon once I receive them. Best regards, Greg Kazz Chairman SLS-SLP WG On 1/18/13 11:07 AM, "Moury Gilles" wrote: >Dear Greg and SDLS WG member, > >Given the responses I had to my poll for the date, I propose we hold our >telecon on "SDLS-COP interaction" on Thursday February 21st, 16:00-19:00 >CET. Ignacio : could you please arrange the telecon from ESA ? (our >telecon system at CNES is definitely not user friendly for non french >natives !!!). > >Best regards and have a good week-end, > >Gilles > >Gilles MOURY >CNES Toulouse >-----Message d'origine----- >De : Moury Gilles >Envoyé : lundi 14 janvier 2013 19:09 >À : sls-sea-dls at mailman.ccsds.org; Greg J. Kazz >Objet : Selecting a date for "SDLS-COP interaction" telecon > >Dear Greg and SDLS WG member, > >While updating the SDLS and TC Space Data Link books, questions about >communication and security errors handling and reporting emerged (see >attached mails from Ignacio). In particular interaction between COP (TC >retransmission protocol) and SDLS needs to be sorted out and eventually >specified in an update of the COP book. I propose to hold a telecon on >the subject in the Feb/march timeframe before our next meeting in >Bordeaux so we can finalize our proposal for COP update in Bordeaux. > >I propose the following dates : > >-February : > >- 21 >- 25 >- 26 >- 27 >- 28 > >- March : > >- 1 >- 4 >- 5 >- 6 >- 7 >- 8 > >Could you please indicate your availability, so I can select the optimal >date. Telecon would start at 16:00 CET for 2-3 hours. > >Best regards, > >Gilles > >Gilles MOURY >CNES Toulouse > >-----Message d'origine----- >De : Moury Gilles >Envoyé : lundi 14 janvier 2013 18:49 >À : 'Ignacio.Aguilar.Sanchez at esa.int' >Cc : sls-sea-dls at mailman.ccsds.org; Greg J. Kazz >Objet : RE: [Sls-sea-dls] SDLS Security Failure Report > >Dear Ignacio, > >Happy new year to you and all SDLS WG members. I hope 2013 will be the >publication year of our long awaited SDLS blue book ! > >I will circulate a Doodle poll to set up the telecon on "SDLS-COP >interaction" in February. > >In the mean time, are we likely to start our combined agency reviews for >SDLS and SDLP books as planned in Cleveland ? What is the status of the >coordinated update of the SDLS book and of the SDLP books ? > >Best regards, > >Gilles > >Gilles MOURY >CNES Toulouse > >-----Message d'origine----- >De : Ignacio.Aguilar.Sanchez at esa.int >[mailto:Ignacio.Aguilar.Sanchez at esa.int] >Envoyé : mardi 8 janvier 2013 11:30 >À : Moury Gilles >Cc : sls-sea-dls at mailman.ccsds.org >Objet : RE: [Sls-sea-dls] SDLS Security Failure Report > >Dear Gilles, > >First of all happy new year to you and all CCSDS colleagues in copy! > >Sorry to come back now with my answer. I was on leave during that week, >was >back to my office yesterday and still catching up with past e-mail and >actions. > >I think holding a telecon before the meeting is a good move. We need to >explore the territory a bit before we plunge into more detail. I would >expect >we will need to go further during the Spring meeting. > >Concerning relevant experience I need to investigate a bit. In my view the >closest thing to what we do in SDLS will be flown with the GMES Sentinels >1, >2 and 3. Furthermore, there is another project that also has security and >is >already flying. However, it is not as close to SDLS as the solution >implemented in the GMES Sentinels. Still, I will investigate it. > >Concerning proposals I would rather wait to first understand well which >are >the issues we have to worry about. > >Let's organise this telecon. I would propose to hold it in February so >that >we can prepare a bit beforehand. > >Kind regards, > >Ignacio > > >|------------> >| From: | >|------------> > >>------------------------------------------------------------------------- >>------------------------------------------------------------------------- >>----| > |Moury Gilles > > | > >>------------------------------------------------------------------------- >>------------------------------------------------------------------------- >>----| >|------------> >| To: | >|------------> > >>------------------------------------------------------------------------- >>------------------------------------------------------------------------- >>----| > |"Ignacio.Aguilar.Sanchez at esa.int" > > | > >>------------------------------------------------------------------------- >>------------------------------------------------------------------------- >>----| >|------------> >| Cc: | >|------------> > >>------------------------------------------------------------------------- >>------------------------------------------------------------------------- >>----| > |"sls-sea-dls at mailman.ccsds.org" > > | > >>------------------------------------------------------------------------- >>------------------------------------------------------------------------- >>----| >|------------> >| Date: | >|------------> > >>------------------------------------------------------------------------- >>------------------------------------------------------------------------- >>----| > |17/12/2012 15:19 > > | > >>------------------------------------------------------------------------- >>------------------------------------------------------------------------- >>----| >|------------> >| Subject: | >|------------> > >>------------------------------------------------------------------------- >>------------------------------------------------------------------------- >>----| > |RE: [Sls-sea-dls] SDLS Security Failure Report > > | > >>------------------------------------------------------------------------- >>------------------------------------------------------------------------- >>----| >|------------> >| Sent by: | >|------------> > >>------------------------------------------------------------------------- >>------------------------------------------------------------------------- >>----| > |sls-sea-dls-bounces at mailman.ccsds.org > > | > >>------------------------------------------------------------------------- >>------------------------------------------------------------------------- >>----| > > > > > >Dear Ignacio, > >OK to organize before next meeting a telecon on interaction of SDLS with >COP. >For the time being, we update the 3 SDLP books (AOS, TC and TM) only >adding >section 6 (SDLP with SDLS option). The need to update COP blue book with >an >"SDLS option" section will be decided during the proposed telecon. I agree >with you Ignacio that there are many implications behind the various >possible >interactions. Do you have on ESA side any experience/proposal you could >share >with the SDLS and SLP WGs ? > >Best regards, > >Gilles > >Gilles MOURY >CNES Toulouse >-----Message d'origine----- >De : Ignacio.Aguilar.Sanchez at esa.int >[mailto:Ignacio.Aguilar.Sanchez at esa.int] > >Envoyé : vendredi 14 décembre 2012 08:54 >À : Moury Gilles >Cc : Greenberg, Edward (313B); sls-sea-dls at mailman.ccsds.org >Objet : RE: [Sls-sea-dls] SDLS Security Failure Report > >Dear Gilles, > >I think this is a topic that deserves detailed analysis and discussion. >Interfacing the COP machinery may have pros and cons. > >I am of the opinion that in order to differentiate the source of errors >for a >TC failed frame, it would better to keep separate the reporting and >actions >concerning communications and security failures. >Reporting an authentication failure with an additional flag (instead of >the >logical OR of the two reasons for failure implied in your response) in the >CLCW could a priori be useful. >However, automatic re-transmission of a TC frame that failed >authentication >verification does not seem to me a good idea. > >But I think there is an issue concerning the interaction of the two >protocols >that needs to be addressed in detail, in particular when security fails >and >the channel does not. Just an example: should the FOP stop if it 'sees' a >failed authentication reported? Should the FOP see this report in the >first >place? I assumed it should since a priori it does not seem to make sense >to >me to keep pushing TC frames up when the on-board channel appears to be >blocked by the authentication function. Someone somehow should understand >what's happening before keeping pushing frames. > >My recommendation: let's not rush into solving this question. Subject for >a >detailed problem definition and analysis with proposals to be discussed >maybe >in a dedicated telecon or in Spring meeting together with SLP. > >Kind regards, > >Ignacio > > >|------------> >| From: | >|------------> > >>------------------------------------------------------------------------- >>------------------------------------------------------------------------- >>----| > > |Moury Gilles >| > >>------------------------------------------------------------------------- >>------------------------------------------------------------------------- >>----| > >|------------> >| To: | >|------------> > >>------------------------------------------------------------------------- >>------------------------------------------------------------------------- >>----| > > |"Greenberg, Edward (313B)" >| > >>------------------------------------------------------------------------- >>------------------------------------------------------------------------- >>----| > >|------------> >| Cc: | >|------------> > >>------------------------------------------------------------------------- >>------------------------------------------------------------------------- >>----| > > |"sls-sea-dls at mailman.ccsds.org" >| > >>------------------------------------------------------------------------- >>------------------------------------------------------------------------- >>----| > >|------------> >| Date: | >|------------> > >>------------------------------------------------------------------------- >>------------------------------------------------------------------------- >>----| > > |13/12/2012 19:56 >| > >>------------------------------------------------------------------------- >>------------------------------------------------------------------------- >>----| > >|------------> >| Subject: | >|------------> > >>------------------------------------------------------------------------- >>------------------------------------------------------------------------- >>----| > > |RE: [Sls-sea-dls] SDLS Security Failure Report >| > >>------------------------------------------------------------------------- >>------------------------------------------------------------------------- >>----| > >|------------> >| Sent by: | >|------------> > >>------------------------------------------------------------------------- >>------------------------------------------------------------------------- >>----| > > |sls-sea-dls-bounces at mailman.ccsds.org >| > >>------------------------------------------------------------------------- >>------------------------------------------------------------------------- >>----| > > > > > > >Ed, > >SDLS is now a function called by SDLP (AOS, TC or TM). If a transfer >frame >is rejected by SDLS receiver, SDLS will return to calling SDLP a flag >indicating the reason for rejection : Œsequence number mismatch¹, ŒMAC >mismatch¹, Œinvalid SPI¹. For TC, TC SDLP receiver will transmit this >'frame >rejected' information to COP FARM. For the COP FARM, whether a frame is >rejected because of "channel decoding" failure or "security check" failure >makes no difference : COP FARM has to report a rejected/missing frame in >CLCW >to trigger retransmission form the ground by TC FOP. At the receiving end, >COP FARM is called by TC SDLP after SDLS, so COP FARM will indifferently >take >into account rejected frames whether for uncorrectable channel errors or >security errors. > >Best regards, > >Gilles > >Gilles MOURY >CNES Toulouse >-----Message d'origine----- >De : Greenberg, Edward (313B) [mailto:edward.greenberg at jpl.nasa.gov] >Envoyé : mercredi 5 décembre 2012 15:19 >À : Moury Gilles >Objet : RE: [Sls-sea-dls] SDLS Security Failure Report > >I have a simple question. Should there be a flag for the COP If the >frame is >rejected by security after it was accepted by the COP. > >-----Original Message----- >From: sls-sea-dls-bounces at mailman.ccsds.org [ >mailto:sls-sea-dls-bounces at mailman.ccsds.org] On Behalf Of Moury Gilles >Sent: Wednesday, December 05, 2012 6:12 AM >To: sls-sea-dls at mailman.ccsds.org >Subject: [Sls-sea-dls] SDLS Security Failure Report > >-----Message d'origine----- >De : Moury Gilles >Envoyé : mercredi 5 décembre 2012 15:09 >À : 'Ignacio.Aguilar.Sanchez at esa.int'; sls-sea-dls@ Cc : >marjorie at delandelong.com Objet : RE: [Sls-sea-dls] SDLS Security Failure >Report > >Dear Ignacio, > >I am in line with your proposals for the 4 questions. > >For the "invalid SPI' failure case : we think we need it because the SDLS >receiver will need to know which SA to use to perform its function. If it >reads an invalid SPI in the security header, it will not be able to >perform >any security checks at all. So we need to distinguish this 'invalid SPI' >failure case upfront and inform the user. SPI can be invalid for at least >3 >reasons : > >- uninstantiated SPI (no SA associated) >- associated SA not active >- associated SA active but not valid for the VC used > >Does it clarify the interest of this failure case ? > >Best regards, >Gilles > >Gilles MOURY >CNES Toulouse > >-----Message d'origine----- >De : sls-sea-dls-bounces at mailman.ccsds.org [ >mailto:sls-sea-dls-bounces at mailman.ccsds.org] De la part de >Ignacio.Aguilar.Sanchez at esa.int Envoyé : mercredi 5 décembre 2012 14:14 À >: >sls-sea-dls@ Cc : marjorie at delandelong.com Objet : [Sls-sea-dls] SDLS >Security Failure Report > > >Dear CCSDS SDLS colleagues, > >Following recent exchanges within the WG on two key SDLS issues raised by >ESA, I would like to follow up on the second issue: the report in case of >failure. > >As you know Gilles and Bruno provided valuable input on the four questions >initially asked (see their e-mail from 28/11/2012). >Last week as part of an ESA internal discussion we tackled the issue >again. >We concluded on the following: > >- Which kind of failure? >As per current Red Book Œsequence number mismatch¹ and ŒMAC mismatch¹. >We need clarification on the proposed Œinvalid SPI¹ by Gilles & Bruno. We >are >not sure about the interest of such report. > >- Which kind of report? >Flags required to signal success or failure and cause; right now at least >two >flags. > >- Destination of the report? >Report to SDLP calling function. SDL protocol to inform user at the >receiving >end. >Further propagation of this report (e.g. TC application) should not be >covered in the current versions of the SDLS and corresponding SDLPs. >As part of the CCSDS SDLS work on Extended Procedures the WG would >complete >the analysis of this point. Such approach will allow to Œclose¹ both the >SDLS >and SDLPs now and postpone further impacts when the Extended Procedures >have >concluded their work. > >- Action as a result of the report? >SDLPs shall discard the Œfailed¹ frames. As per SDLS Red Book, failed >frames >in TM could be delivered for forensics. >Similarly as per previous question, further action should not be covered >in >the current versions of the SDLS and corresponding SDLPs. >As part of the CCSDS SDLS work on Extended Procedures the WG would >complete >the analysis of this point. Such approach will allow to Œclose¹ both the >SDLS >and SDLPs now and postpone further impacts when the Extended Procedures >have >concluded their work. > >Let us know whether the above is agreeable. > >Greg: feel free to provide feedback. > >Kind regards, > >Ignacio >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. > >_______________________________________________ >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 greg.j.kazz at jpl.nasa.gov Thu Jan 24 20:04:08 2013 From: greg.j.kazz at jpl.nasa.gov (Kazz, Greg J (313B)) Date: Thu, 24 Jan 2013 20:04:08 +0000 Subject: [Sls-slp] Yet another draft update to Proximity-1 Green Book Jan 24 2013 Message-ID: <3073AFAD38D0B846893757C13ABA7275234E5F84@ap-embx-sp40.RES.AD.JPL> All, After receiving several new inputs for the Prox-1 GB (including the CRC-32 discussion that was submitted by ESA, other updates due to the inclusion of the LDPC in Prox-1, etc), I have posted this updated draft version on the CWE under: http://tinyurl.com/ajw9k3e Note: It is the intent of the SLP WG to publish an updated Prox-1 GB (current version is 2003) ideally concurrent with the release of the three updated Prox-1 Blue books. So your comments, additions, subtractions, multiplications : ) are welcome before our April 16 meeting! Best regards, Greg -------------- next part -------------- An HTML attachment was scrubbed... URL: