From greg.j.kazz at jpl.nasa.gov Thu Mar 2 21:20:40 2006 From: greg.j.kazz at jpl.nasa.gov (Greg Kazz) Date: Thu, 02 Mar 2006 13:20:40 -0800 Subject: [Sls-slp] Results of CESG poll on Prox-1 Physical Layer Change Message-ID: <6.2.0.14.2.20060302131900.02cc4e80@mail.jpl.nasa.gov> All, Here are the results of the CESG poll. Next poll will be CMC. Greg CESG E-Poll Identifier: CESG-R-2006-02-013: Pink Sheet Approval for Prox-1 Physical Layer Results of CESG poll beginning 6 February 2006 and ending 16 February 2006: ABSTAIN: 0 (0%) APPROVE UNCONDITIONALLY`: 3 (100%) (Peccia, Gerner, Moury) APPROVE WITH CONDITIONS: 0 (0%) DISAPPROVE WITH COMMENT: 0 (0%) Total Respondents: 3 No response was received from the following Area(s): SEA CSS SOIS SIS SECRETARIAT INTERPRETATION OF RESULTS: Approved in the absence of dissent PROPOSED SECRETARIAT ACTION: Generate CMC E-poll From greg.j.kazz at jpl.nasa.gov Fri Mar 24 00:16:44 2006 From: greg.j.kazz at jpl.nasa.gov (Greg Kazz) Date: Thu, 23 Mar 2006 16:16:44 -0800 Subject: [Sls-slp] Fwd: Encapsulation Service Message-ID: <6.2.0.14.2.20060323161346.033b1410@mail.jpl.nasa.gov> SLS-SLPers, This email contains comments from Bob Durst, CCSDS AD for SIS on the resolution to make the Encapsulation Service a Blue Book. See below. The Encapsulation Service (version 4 red book) document which completed agency review can be found at http://public.ccsds.org/sites/cwe/rids/completed.aspx Greg >Date: Thu, 23 Mar 2006 18:05:10 -0500 >From: Thomas Gannett >Subject: Encapsulation Service >X-Sender: tgannett at mail.us.net >To: Greg Kazz >X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 >X-Source-IP: sccrmhc13.comcast.net [204.127.200.83] >X-Source-Sender: tgannett at us.net >X-JPL-spam-score: 0.00% >Original-recipient: rfc822;gkazz at mail.jpl.nasa.gov > >Greg: > >FYI: The CESG poll on encapsulation serve has received at least one >"Approve with Conditions" vote (from Durst). The conditions are below. > >TG > >APPROVE WITH CONDITIONS: 1 (33.33%) (Durst) > >In section 2.2, it is unclear what the conformance requirements >are. There are two protocols (Space Packet and Encapsulation Packet) >under a single service interface. Are both required for conformance? > >The document requires a SANA Implications section to address registered >APIDs and PIDs, and to define procedures to register new APIDs and PIDs. > >The document requires a security implications section. > >Section 3.3.2.2: It is unclear to me whether and how a user of the >service is expected to know the correct GVCID and PVN to use. Are these >statically assigned? Assigned on a per-mission basis? What are the >implications on interoperability? > >Section 4.1, item b) the APID "shall be one of the reserved APIDs" >defined in reference [8]. Are there guidelines or further restrictions on >how a particular APID is chosen? Does interoperability depend on this >choice? In Table 5-2 of reference [8], there appear to be two degrees of >"reserved" -- reserved and assigned to a particular protocol, and reserved >but unassigned. Are any of these fair game? Or was it intended that >these be drawn from the 2040-2044 range? > >Section 4.2.2.1, item g -- this is a poorly worded summary of section >4.2.2.8. Recommend rewording to "Packet Length (0, 1, 2, or 4 octets) -- >See Figure 4-2. > >Section 4.2.2.3 -- "The value '110'..." does this require a RID against >135.0-B-2 (or whatever)? > >Section 4.2.2.6 -- "The extended protocol IDs..." I didn't see this in >reference [8]. Does it require a RID? > >As a note to the secretariat, I'd suggest that we add an Annex for red >books that require modifications to other documents that consolidates >and summarizes those external dependencies. From greg.j.kazz at jpl.nasa.gov Fri Mar 24 18:13:34 2006 From: greg.j.kazz at jpl.nasa.gov (Greg Kazz) Date: Fri, 24 Mar 2006 10:13:34 -0800 Subject: [Sls-slp] Security Implications section In-Reply-To: <44201EFF.3060503@sparta.com> References: <44201EFF.3060503@sparta.com> Message-ID: <6.2.0.14.2.20060324101125.02ff9b68@mail.jpl.nasa.gov> Howie, Bob Durst pointed out to me that the Encapsulation Services RED-4 book that went up to CESG polling to become a blue book is missing a "security implications section". Can you help the SLS-SLP WG in formulating one for it? thanks, Greg From greg.j.kazz at jpl.nasa.gov Fri Mar 24 18:28:10 2006 From: greg.j.kazz at jpl.nasa.gov (Greg Kazz) Date: Fri, 24 Mar 2006 10:28:10 -0800 Subject: [Sls-slp] Re: Encapsulation Service In-Reply-To: <5.1.1.6.2.20060323180013.02617678@mail.us.net> References: <5.1.1.6.2.20060323180013.02617678@mail.us.net> Message-ID: <6.2.0.14.2.20060324100231.02eba720@mail.jpl.nasa.gov> Bob, Thanks for your comments. They have helped make the Encapsulation Service a better specification. My answers to your comments are in ** ** below. thanks, Greg At 03:05 PM 3/23/2006, Thomas Gannett wrote: >Greg: > >FYI: The CESG poll on encapsulation serve has received at least one >"Approve with Conditions" vote (from Durst). The conditions are below. > >TG > >APPROVE WITH CONDITIONS: 1 (33.33%) (Durst) > >In section 2.2, it is unclear what the conformance requirements >are. There are two protocols (Space Packet and Encapsulation Packet) >under a single service interface. Are both required for conformance? **Both protocols can be used to encapsulate other protocols. For example, CFDP can be encapsulated into space packets by using APID=2045 or into an Encapsulation packet by using PID = '110'. I need to know more about what you are expecting in terms of "conformance requirements". The encapsulation service specifies the inputs, what protocols are used to do the encapsulating, and references the Space Link Identifiers document, which supplies all of the IDs one needs in order to carry out the service.** >The document requires a SANA Implications section to address registered >APIDs and PIDs, and to define procedures to register new APIDs and PIDs. ** All of the IDs used by the Encapsulation Service are defined in the Space Link Identifiers spec. This is true for all of the link layer protocols. Therefore, it is the Space Link Identifiers book that requires a SANA implication section, not Encap. service. APIDs and PIDs are defined in the Space Link Identifiers book which is referenced in section 2.3 ** >The document requires a security implications section. ** I will work with Howie on how to accomplish this ** >Section 3.3.2.2: It is unclear to me whether and how a user of the >service is expected to know the correct GVCID and PVN to use. Are these >statically assigned? Assigned on a per-mission basis? What are the >implications on interoperability? ** GVCID = SCID + VCID. SCID is statically assigned. VCID is an enterprise or project managed parameter. CCSDS recognizes certain PVNs. All of these IDs are defined and their values are listed (if not a managed parameter) in the Space Link Identifiers spec. For things like PVN it's very static. For APIDs, an enterprise has to really manage these across the enterprise in order for interoperability to happen. Global enterprise APIDs begin to happen in these cases. ** >Section 4.1, item b) the APID "shall be one of the reserved APIDs" >defined in reference [8]. Are there guidelines or further restrictions on >how a particular APID is chosen? Does interoperability depend on this >choice? In Table 5-2 of reference [8], there appear to be two degrees of >"reserved" -- reserved and assigned to a particular protocol, and reserved >but unassigned. Are any of these fair game? Or was it intended that >these be drawn from the 2040-2044 range? ** Again APIDs are a managed parameter by an enterprise except for the ones defined in the CCSDS Space Link Identifiers book. There are no further restrictions except the ones managed by the enterprise. Yes, interoperability is an issue for the management of those apids. It is intended that 2040-2044 be used for encapsulation by space packets. ** >Section 4.2.2.1, item g -- this is a poorly worded summary of section >4.2.2.8. Recommend rewording to "Packet Length (0, 1, 2, or 4 octets) -- >See Figure 4-2. ** Agreed. It will be changed to Packet Length (0, 1, 2, or 4 octets). ** >Section 4.2.2.3 -- "The value '110'..." does this require a RID against >135.0-B-2 (or whatever)? ** The PID value '110" needs to be added to Space Link Identifiers blue book via a new pink sheet ** >Section 4.2.2.6 -- "The extended protocol IDs..." I didn't see this in >reference [8]. Does it require a RID? ** A new table called "Extended Protocol IDs" needs to be added to the Space Link Identifiers blue book via the new pink sheet. ** >As a note to the secretariat, I'd suggest that we add an Annex for red >books that require modifications to other documents that consolidates >and summarizes those external dependencies. ** I agree ** From howard.weiss at sparta.com Fri Mar 24 21:34:20 2006 From: howard.weiss at sparta.com (Howard Weiss) Date: Fri, 24 Mar 2006 16:34:20 -0500 Subject: [Sls-slp] Re: Security Implications section In-Reply-To: <6.2.0.14.2.20060324101125.02ff9b68@mail.jpl.nasa.gov> References: <44201EFF.3060503@sparta.com> <6.2.0.14.2.20060324101125.02ff9b68@mail.jpl.nasa.gov> Message-ID: <442465DC.7010401@sparta.com> Sure. Do you have the outline for the security section that you can fill in as best you can and then I can help fill in any perceived gaps? howie Greg Kazz wrote: > Howie, > > Bob Durst pointed out to me that the Encapsulation Services RED-4 book > that went up to CESG polling to become a blue book is missing a > "security implications section". Can you help the SLS-SLP WG in > formulating one for it? > > thanks, > Greg > > -- Howard Weiss SPARTA, Inc. 7075 Samuel Morse Drive Columbia, MD 21046 410.872.1515 x201 || 410.872.8079 (fax) -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg.j.kazz at jpl.nasa.gov Fri Mar 24 22:52:34 2006 From: greg.j.kazz at jpl.nasa.gov (Greg Kazz) Date: Fri, 24 Mar 2006 14:52:34 -0800 Subject: [Sls-slp] Space Link Identifiers pink Sheets Message-ID: <6.2.0.14.2.20060324144712.02eb3ec0@mail.jpl.nasa.gov> Tom, Attached is the Space Link Identifiers Pink Sheet. The changes are in Section 7.7 Protocol ID (PID): a. added a PID for CFDP b. added a PID for signaling the Extended protocol ID c. added a new table to define the Extended protocol IDs All of these changes were discussed and approved by the WG when we worked on modifying the Encapsulation Service. However, we forgot about the value assignments in this document. Once you update this pink sheet, can you make it available for agency review or is there another intermediate step involved? thanks, Greg -------------- next part -------------- A non-text attachment was scrubbed... Name: 135x0b2[master]_gjk.doc Type: application/msword Size: 273920 bytes Desc: not available URL: