From greg.j.kazz at jpl.nasa.gov Tue Jul 17 17:56:52 2012 From: greg.j.kazz at jpl.nasa.gov (Kazz, Greg J (313B)) Date: Tue, 17 Jul 2012 17:56:52 +0000 Subject: [Sls-slp] Hotel rooms at the host hotel for the Fall 2012 CCSDS meeting - Cleveland, OH USA Message-ID: Dear SLP or NGU member, Please go to the following URL to view the logistics for the CCSDS Fall 2012 technical meetings in Cleveland, OH. USA. The meetings will be held at the Renaissance Hotel Cleveland. Futher information including how to sign up for a room is at: http://public.ccsds.org/meetings/2012Fall/default.aspx Best regards, Greg Kazz Chairman CCSDS SLS-SLP and SLS-NGU WGs -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg.j.kazz at jpl.nasa.gov Tue Jul 24 22:49:04 2012 From: greg.j.kazz at jpl.nasa.gov (Kazz, Greg J (313B)) Date: Tue, 24 Jul 2012 22:49:04 +0000 Subject: [Sls-slp] FW: TM, AOS, TC Security Section Preview In-Reply-To: Message-ID: Dear SLS-SLP members, Please let me know what you think of the following addtions to the existing pink sheets for AOS and TM… along with these new pink sheet to TC for the addition of the security sections in AOS, TM, and TC. Attached are the proposed pink sheet pdf files. We plan to discuss these changes at the Fall Meeting in Cleveland. The SLP CWE under Fall 2012 Cleveland Directory contains these changes in Word. In general I have: 1. Added the normative reference to the soon to be Blue CCSDS SDLS Protocol in Chapter 1 to TM, TC, AOS 2. In Chapter 4, I added the requirement to use the CCSDS SDLS protocol. 3. In Chapter 4 (TM/AOS), I added the requirement on how to calculate the frame length inclusive of all cases. 4. In Chapter 4, (TC) I added the security header/trailer (when present) to the requirement for frame length calculation. Best regards, Greg -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 132x0p11[final]_TM.pdf Type: application/pdf Size: 1410369 bytes Desc: 132x0p11[final]_TM.pdf URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 732x0p21[final]_AOS.pdf Type: application/pdf Size: 1370527 bytes Desc: 732x0p21[final]_AOS.pdf URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 232x0b2[final]_TC.pdf Type: application/pdf Size: 1714414 bytes Desc: 232x0b2[final]_TC.pdf URL: From greg.j.kazz at jpl.nasa.gov Tue Jul 31 16:13:15 2012 From: greg.j.kazz at jpl.nasa.gov (Kazz, Greg J (313B)) Date: Tue, 31 Jul 2012 16:13:15 +0000 Subject: [Sls-slp] FW: inconsistent bit numbering for CLCWs in AOS and TM Space Data Protocol specs In-Reply-To: Message-ID: Dear SLP, A new RID for disposition at the SLP meeting in Cleveland. Please see below. Thanks John! Greg Kazz Chairman CCSDS SLS-SLP WG From: John Pietras > Date: Monday, July 30, 2012 2:46 PM To: "Kazz, Greg J (313B)" > Subject: inconsistent bit numbering for CLCWs in AOS and TM Space Data Protocol specs Greg, There’s inconsistent usage of “first” bit in the AOS and TM Space Data Protocol specs (732.0-B-2 and 132.0-B-1, respectively). The boilerplate section 1.6.3, Conventions, states “The first bit in the field to be transmitted (i.e., the most left justified when drawing a figure) is defined to be ‘Bit 0’ ”, and that’s also illustrated in figure 1-1. However, in section 4.1.5 (OPERATIONAL CONTROL FIELD) the following statements appear: 4.1.5.4 The leading bit of the field, i.e., bit 0, shall contain a Type Flag with the following meanings: … 4.1.5.5 The first bit of a Type-2-Report (i.e., bit 1 of the Operational Control Field) shall indicate the use of this report as follows: … The last sentence of NOTE 2 under 4.1.5.5 reads “This issue of the Recommendation does not define the use of Type-2-Reports; however, it reserves the possibility to do so in future issues by restricting the utilization of the first bit.” That is, 4.1.5.4 uses the otherwise-undefined term “leading bit” to refer to bit 0, and 4.1.5.5 uses “first bit” to refer to bit 1. To be consistent with the Conventions ion 1.6.3: - 4.1.5.4 should read “The first bit of the field, i.e., bit 0, shall contain a Type Flag with the following meanings: …” - 4.1.5.5 should read “The second bit of a Type-2-Report (i.e., bit 1 of the Operational Control Field) shall indicate the use of this report as follows: …”, and - The last sentence of NOTE 2 under 4.1.5.5 should read “This issue of the Recommendation does not define the use of Type-2-Reports; however, it reserves the possibility to do so in future issues by restricting the utilization of the second bit.” Something to file away in your list of errata to eventually be fixed. Regards, John -------------- next part -------------- An HTML attachment was scrubbed... URL: