[Cesg-all] April CESG Poll Results
Oliver Brian (BTAS)
brian.oliver at btas.com
Tue May 2 10:51:57 EDT 2006
Skipped content of type multipart/alternative-------------- next part --------------
CESG E-Poll Identifier: CESG-R-2006-03-002: Green Book approval of Security Threats Against Space Missions, CCSDS 350.1-G-1
Results of CESG poll beginning 16 March 2006 and ending 14 April 2006:
ABSTAIN: 0 (0%)
APPROVE UNCONDITIONALLY`: 5 (71%) (Lapaian, Peccia, Shames, Moury, Plancke)
APPROVE WITH CONDITIONS: 2 (29%) (Durst, Gerner)
DISAPPROVE WITH COMMENT: 0 (0%)
Total Respondents: 7
No response was received from the following Area(s):
CONDITIONS:
Section 1.6 (Definitions) -- If these definitions are shared by a broader community, that would be a good thing, and we should cite the source of the definitions. If they are definitions unique to this document, we should probably say so.
Section 3.2, Paragraph beginning with "A number of generic threats to CCSDS...": The penultimate sentence of the paragraph states that failures are more critical in space missions "because of the inability to make repairs." I'd suggest rewording to "because of the difficulty and expense involved in making repairs." The Hubble Space Telescope repair mission is an example where repairs were possible, and repairs are more-or-less routine on long-duration manned missions.
Section 3.4, Paragraph 2: "... will be agreed upon and adopted by all Space Mission Security Officers." Please clarify -- is this within an Agency, or within CCSDS?
Section 3.3 Threat Analysis methodology
Figure 3-1, page 3-3 does not indicate the starting point for this process. It is recommended to include a "start" arrow to the boxes "determine threats" and "determine nature of vulnerability".
The statement "If the technical means is very expensive, but the likelihood of exploitation of the vulnerability is low, then a policy response would be in order" found on the paragraph under figure 3-1, page 3-3 needs edition. The statement implies that one has the choice to select either technical means or policy responses to counter threats. There is not often such a choice. For instance for threats like denial-of-service (jamming), policy responses do not help.
Figure 3-2, page 3-4 includes inaccurate text in the pink box: a threat not counteracted becomes a RISK with loss expectancy value > 0, NOT a vulnerability. A risk is a vulnerability combined with a threat with a specified probability.
Section 4.3 Illustrative Mission Threats
Tables 4-1, 4-2, 4-3, 4-4 and 4-5 include a column titled "Probability". The assignment of probabilities to threats is part of a RISK Analysis, not of a Threat Analysis. Leaving that column would extend the scope of the document beyond what is implied by its title. Furthermore, the values included in this column have been and will continue to be, the subject of controversy. The proposal is to remove the column from the tables. If this is not considered palatable by CCSDS, a clear disclaimer sentence shall be included in the body text, not on footnotes as it is the case now.
SECRETARIAT INTERPRETATION OF RESULTS: Approved with conditions
PROPOSED SECRETARIAT ACTION: Send conditions to CESG. WG needs to resolve conditions, and then resumbit to CESG for CMC poll creation.
******************************************************************************************
CESG E-Poll Identifier: CESG-R-2006-03-003: Orange Book approval of Low Density Parity Check Code for Rate 7/8
Results of CESG poll beginning 16 March 2006 and ending 14 April 2006:
ABSTAIN: 2 (33%) (Durst, Plancke)
APPROVE UNCONDITIONALLY`: 0 (0%)
APPROVE WITH CONDITIONS: 2 (33%) (Shames, Gerner)
DISAPPROVE WITH COMMENT: 2 (33%) (Lapaian, Peccia)
Total Respondents: 6
No response was received from the following Area(s):
CONDTITIONS:
Orange books it is an easy solution to give a "standard like" color to a non agreement between agencies around an unique proposal.
I hesitate between "abstain" and "disapprove".
This approach will result in a proliferation of Orange Books (mainly due to disagreement between agencies or even more serious due to disagreement within an Agency), weakening the main CCSDS goal to produce Standards (e.g. BB).
We are now confronted with 2 orange books (one from GFSC and one from JPL). When will ESA or CNES orange books be issued ?
Instead of reaching consensus, we are fomenting the disagreement via Orange Books.
Pg 1-1, fig 1-1 does not reproduce correctly, it needs to be fixed.
The code specified in this document is responsive to a particular set of near Earth requirements for high rate and low error floor. The code family specified in 131x201 is responsive to a set of requirements for Cislunar and deep space environments.
This is similar to the situation that pertains in the modulation standards, where there are several different schemes accepted for different operating regimes. Both of these code specificaiton are experimental and both should be accepted as such unless there is strong technical disagreement with the codes themselves or these specifications.
Futher experience with these codes, and any others that might be specified as experimental, should result in eventual consensus on sets of operational domain requirements and suitable code families.
The Orange Book is approved unconditionally and the text below is a supporting comment to this approval.
This Orange Book has been produced in full conformity with the CCSDS Restructuring Manual CCSDS A02.1-Y. In particular, it denotes a specification that is part of some research as reported by the originating Agency. Orange Books are only documenting solutions brought forward by one Agency so that other Agencies can evaluate and reproduce performance results.
In order to avoid any ambiguity on the purpose of this book, care has been taken on the text in the ‘Authority’ and ‘Foreword’ pages. Likewise, any occurrence of the words ‘recommended’ or ‘recommendation ‘have been removed from the text to avoid any confusion with a Blue Book.
It is the understanding of the SLS area that, given the experimental nature of the Orange Book, there is no prescription against introduction of several Orange Books covering the same application requirements. Redundancy of Orange Books allows for reliable cross-evaluation of state-of-the-art solutions by participating agencies and thus contributing to the emergence of a common solution.
SECRETARIAT INTERPRETATION OF RESULTS: Disapproved
PROPOSED SECRETARIAT ACTION: Send conditions to CESG
******************************************************************************************
CESG E-Poll Identifier: CESG-R-2006-03-004: Orange Book approval of Low Density Parity Check Code Family
Results of CESG poll beginning 16 March 2006 and ending 14 April 2006:
ABSTAIN: 2 (33%) (Durst, Plancke)
APPROVE UNCONDITIONALLY`: 0 (0%)
APPROVE WITH CONDITIONS: 2 (33%) (Shames, Gerner)
DISAPPROVE WITH COMMENT: 2 (33%) (Lapaian, Peccia)
Total Respondents: 6
No response was received from the following Area(s):
CONDTITIONS:
Orange books it is an easy solution to give a "standard like" color to a non agreement between agencies around an unique proposal.
I hesitate between "abstain" and "disapprove".
This approach will result in a proliferation of Orange Books (mainly due to disagreement between agencies or even more serious due to disagreement within an Agency), weakening the main CCSDS goal to produce Standards (e.g. BB).
We are now confronted with 2 orange books (one from GFSC and one from JPL). When will ESA or CNES orange books be issued ?
Instead of reaching consensus, we are fomenting the disagreement via Orange Books.
On pg 6-1, Sec 6 synchronization, in line 6 there is a reference to a Turbo codeblock, it should refer to a LDPC codeblock.
The Orange Book is approved unconditionally and the text below is a supporting comment to this approval.
This Orange Book has been produced in full conformity with the CCSDS Restructuring Manual CCSDS A02.1-Y. In particular, it denotes a specification that is part of some research as reported by the originating Agency. Orange Books are only documenting solutions brought forward by one Agency so that other Agencies can evaluate and reproduce performance results.
In order to avoid any ambiguity on the purpose of this book, care has been taken on the text in the ‘Authority’ and ‘Foreword’ pages. Likewise, any occurrence of the words ‘recommended’ or ‘recommendation ‘have been removed from the text to avoid any confusion with a Blue Book.
It is the understanding of the SLS area that, given the experimental nature of the Orange Book, there is no prescription against introduction of several Orange Books covering the same application requirements. Redundancy of Orange Books allows for reliable cross-evaluation of state-of-the-art solutions by participating agencies and thus contributing to the emergence of a common solution.
SECRETARIAT INTERPRETATION OF RESULTS: Disapproved
PROPOSED SECRETARIAT ACTION: Send conditions to CESG
******************************************************************************************
CESG E-Poll Identifier: CESG-R-2006-03-005: Approval of Reference Architecture for Space Data Systems (RASDS) for Agency Red-1 review
Results of CESG poll beginning 29 March 2006 and ending 14 April 2006:
ABSTAIN: 1 (12.5%) (Gerner)
APPROVE UNCONDITIONALLY`: 5 (62.5%) (Lapaian, Peccia, Shames, Moury, Plancke)
APPROVE WITH CONDITIONS: 2 (25%) (Durst, Hooke)
DISAPPROVE WITH COMMENT: 0 (0%)
Total Respondents: 8
No response was received from the following Area(s):
CONDITIONS:
See file RASDS-comments-ajh-11Apr06.doc
Basically I recommend clarifying the boilerplate and applicability to state that use of RASDS is purely voluntary
Clarify the effect of approval of this document on CCSDS Working Groups and Documents.
Section 2.5, first sentence: I am not sure how the phrase "..., and where the connections between elements, the physics of motion, and external environmental forces must be considered." From context, this is part of the motivation for the Connectivity Viewpoint, but I suspect I'm not reading the sentence correctly or there's a word missing.
Section 2.6, 2nd paragraph, first sentence: need space between comma and "hardware."
Section 2.6, 7th paragraph (beginning "The selection of specific..."): Reference to figure 2-7 should be to figure 2-6.
Section 2.6, 8th paragraph: Expand acronym "SAP."
Section 2.8, reference to figure 2-9 should be to figure 2-8 (in both Para 1 and Para 2).
Section 2.9.2: References to figures 2-10 (a, b, and c) should be to Figures 2-9 (a, b, and c, respectively).
Section 2.9.3: Reference to figure 2-11 in paragraph 2 should be to figure 2-10. Reference to figure 2-10 in paragraph 4 should be to figure 2-9, I believe. However, I do not see in figures 2-9 a, b, or c, a "pipe" representation that provides inter-layer services as does a SAP (a la the ovals in figure 2-10). The only pipes I see in any of the figures 2-9 are intra-layer.
Section 3 seems out of place. It introduces concepts that have already been used. For example, Section 2.1 uses "encapsulation, abstraction and behaviour [sic]." It goes on to explain encapsulation at some length, but doesn't mention abstraction or behavior. Section 3.1 defines abstraction and encapsulation (I'm still waiting for behavior -- whoops there it is in 3.2.4). My recommendation is to either remove the terminology from section 2 that is defined in section 3, or to move section 3 ahead of section 2, or to provide sufficient explanation within section 2 so that it stands alone.
Section 4.3, Paragraph 6. Sentence 2: "How each Space Enterprise is decomposed into component Enterprise Objects highly depends on each space data system,..." This is confusing to me. It seems that the space data system should be the *result* of this decomposition, not the constraining entity. It would make sense if this paragraph is describing building a representation of an *existing* space data system, in which case the text should make that clear.
Section 4.4.1, footnote 1: "Detailed descriptions of the attributes of Enterprise Objects will be provided in a later issue of this document." Is it OK to go to ballot with an incomplete document? Similarly, Section 5.3, note 2, and section 5.4.1, note 3.
Section 5.3: broken link in the 2nd sentence of the paragraph after Table 5-1: "...for the more application oriented Functional Objects shown intable Error! Reference source not found.."
Section 6: Although the word "scheduling" is mentioned in paragraph 2, the concept of a "schedule" doesn't seem to appear in any of the attributes of the Links, Nodes, or what have you. For Space Data Systems, "schedule" seems like an important concept to call out explicitly, especially when one considers that the scheduled availability of a node may not be directly derivable from the laws of motion governing it (for example, a remote node may be in view, but I don't have time scheduled on the ground station).
Section 6.3.1, Last sentence of 3rd Paragraph after Figure 6-1: Fragmentary sentence: "...selected to deal with these behavioral and environmental " No ending to sentence.
Table 6-2: I don't believe that this table is intended to be prescriptive, based on the "Typical" in the title, but it seems mistaken to restrict the "Space Link" element to only point-to-point relationships as is currently done. I would be reluctant to rule out a broadcast network among multiple spacecraft to support, for example, constellation formation flying.
Is the clip-art in, for example Figure 6-2, Figure 6-4, Figure 6-5, etc. serving a purpose (other than bloating the size of the document)? If this is a language for architectural specification, it seems that such graffiti has no place.
Figures 6-2 through 6-5: Are these actually adequate representations of the Connectivity View? If so, then I believe that they're useless. Where are the attributes specified? How can I make any reasonable trade offs with these cartoons? If there are attributes associated with these nodes and links, why are they not shown? How are they supposed to be shown? Is there supposed to be traceability between Figure 6-2 and Figure 6-4? If so, why did the name of some of the nodes change? (e.g. "Tracking Station" in Figure 6-2 became "Ground Tracking Station" in Figure 6-4.) These boxes, in the absence of their attributes, provide little to no value. If this is supposed to be an example that demonstrates the utility of a connectivity view, it fails. It *might* be improved by the addition of the actual information that imbues each cartoon with meaning, so that we might understand how these things might be useful as tools in reasoning about the connectivity of a space mission. But it's not useful as is.
7.2 “The Communications Viewpoint is an engineering and technical view of a space data system that focuses on the mechanisms and functions required to design and implement protocols and communications standards for a space data system,
” So it appears that this section is supposed to be a tool to help me design and implement protocols. I don’t believe that there are any real protocol design tools put forth here. At best, the section presents a restatement of some protocol representation tools.
7.3.1 -- the first sentence of the section contains a reference to footnote 4, but I cannot find footnote 4.
Not all of these comments need to be resolved prior to sending the document out for review. The comments on sections 3 and 4.4.1 seem to be deferrable until later. I'm conflicted on whether the comment on section 6 as a whole and the final comment on Figures 6-2 through 6-5 need to be resolved prior to agency review. I believe that the document is not particularly useful until these are resolved, but I'm willing to be swayed. I believe that the comments on section 7 can (easily) and should be resolved prior to release.
SECRETARIAT INTERPRETATION OF RESULTS: Approved with conditions
PROPOSED SECRETARIAT ACTION: Send conditions to CESG. WG needs to resolve conditions, and then resumbit to CESG for CMC poll creation.
******************************************************************************************
CESG E-Poll Identifier: CESG-R-2006-03-006: Approval of Space Link Identifiers Pink Sheets for CCSDS Agency Review
Results of CESG poll beginning 31 March 2006 and ending 14 April 2006:
ABSTAIN: 0 (0%) (Lapaian, Peccia, Shames, Gerner, Gilles, Plancke)
APPROVE UNCONDITIONALLY`: 6 (86%)
APPROVE WITH CONDITIONS: 1 (14%) (Durst)
DISAPPROVE WITH COMMENT: 0 (0%)
Total Respondents: 7
No response was received from the following Area(s):
CONDTITIONS:
Tables 7-9a and 7-9b are incorrect. Port Identifier "010" identifies "Space Packets", and references [6], the SPP document. This means that Prox 1 only carries a subset of the network layer protocol data units standardized by CCSDS (and identified in Table 7-6). If the intention was to fully support all network data units that CCSDS endorses, then change the text from "Space Packets" to "Packets" and change the references section from "[6]" to "[6], [7], [13], [17]." If the intention was to ONLY support SPP, then change my Response to Disapprove with Comment.
SECRETARIAT INTERPRETATION OF RESULTS: Approved with conditions
PROPOSED SECRETARIAT ACTION: Send conditions to CESG. WG needs to resolve conditions, and then resumbit to CESG for CMC poll creation.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: RASDS-comments-ajh-11Apr06.doc
Type: application/msword
Size: 104960 bytes
Desc: RASDS-comments-ajh-11Apr06.doc
Url : http://mailman.ccsds.org/pipermail/cesg-all/attachments/20060502/648eeb29/RASDS-comments-ajh-11Apr06-0001.doc
More information about the CESG-all
mailing list